1 |
>> Every other solution out there has this one little problem that people |
2 |
>> seem to |
3 |
>> ignore. |
4 |
>> |
5 |
>> Per RFC, if you accept the connection and the mail, you will deliver it. |
6 |
>> That's what it says. It also says this since days long before spam |
7 |
>> problems, |
8 |
>> but still. We all conveniently ignore this if we are talking about what |
9 |
>> *we* |
10 |
>> consider spam, and by "we" I mean "everyone who cares to take an interest |
11 |
>> except the actual recipient". |
12 |
>> |
13 |
>> ... Yet we accepted the mail implying that we will deliver it... |
14 |
> |
15 |
> I don't think it's necessary to break RFC if you reject based on a bogus |
16 |
> HELO. The connection is initiated, but you do not get as far as accepting |
17 |
> the mail. |
18 |
> |
19 |
>> Instantly, 85% of the problem goes |
20 |
>> away, and I have numbers to prove it. |
21 |
> |
22 |
> 85% of the problem goes away if you use Spamhaus, and that doesn't require |
23 |
> you to discard legitimate email. |
24 |
> |
25 |
>> And why is a user on a DSL range running a mail server anyway? |
26 |
> |
27 |
> Personally, from my own point of view, it's so that I can see clearly that a |
28 |
> message has been delivered. |
29 |
> |
30 |
> EG: |
31 |
> |
32 |
> Sep 1 18:42:22 compaq postfix/smtp[6121]: A66A2137D25: |
33 |
> to=<XXX@××××××××.uk>, relay=mx1.mail.eu.yahoo.com[217.12.11.64], delay=2, |
34 |
> status=sent (250 ok dirdel) |
35 |
> |
36 |
> I get complaints ALL the time from my customers, "oh, my brother / mother / |
37 |
> customer / supplier says they sent me an email and I never received it". The |
38 |
> only way I can debug this is to send them test messages (sometimes daily) |
39 |
> and tell them to let me know if they don't arrive. |
40 |
> |
41 |
> If a customer comes to you with a log entry that looks like the above, |
42 |
> referring to your server's hostname & IP, complaining the message was never |
43 |
> delivered, then you can, reluctantly, look in the problem, grepping for |
44 |
> A66A2137D25. |
45 |
> |
46 |
> If the customer comes to you with a log entry like the above with |
47 |
> relay=smtp.my-isp.com then your response will be "oh, we probably never got |
48 |
> the message from your ISP". I presumably can log a support issue with my ISP |
49 |
> & expect them to come up with the log of the message being delivered to your |
50 |
> servers, but it's simply easier if I can debug non-deliveries myself. |
51 |
> |
52 |
>> The vast |
53 |
>> overwhelming majority of them are Windows zombies! |
54 |
> |
55 |
> Which are easily filtered by checking their HELO resolves to an independent |
56 |
> domain. Or am I missing something here? |
57 |
> |
58 |
> The remainder of those you're inefficiently filtering are Linux enthusiasts |
59 |
> running Postfix on their Gentoo boxes. |
60 |
|
61 |
Yeah, I was planning on setting up postfix on my home Gentoo box too. |
62 |
I guess I could relay through my ISP to avoid delivery problems like |
63 |
this. |
64 |
|
65 |
Why hasn't greylisting been mentioned? I greylist and it ends up |
66 |
blocking at least 99% of spam in my experience. |
67 |
|
68 |
- Grant |
69 |
|
70 |
|
71 |
>> And finally, my mail servers are mine and I make decisions about them, not |
72 |
>> someone else. |
73 |
> |
74 |
> Sure, but you're making unilateral decisions about the validity of emails on |
75 |
> behalf of your customers. And around here the customer comes first. |
76 |
> |
77 |
> If Bob wants to send Alice an email, he shouldn't have to reconfigure his |
78 |
> email server because Fred, the systems administrator at Alice's ISP, is |
79 |
> being a knob about things. |
80 |
> |
81 |
> You may be the exception, having a narrow pipe and being unable to afford |
82 |
> the Spamhaus / DNS lookups to filter spambots in efficient ways. Most |
83 |
> systems administrators using this policy are unable to justify the decision. |
84 |
> |
85 |
>> Best policy is to stipulate in the ISP's terms of service that you will |
86 |
>> not |
87 |
>> accept inbound mail connections from range you feel you cannot trust and |
88 |
>> users |
89 |
>> must use their ISPs mail relay instead. |
90 |
> |
91 |
> You certainly won't get me subscribing to your service. |
92 |
> |
93 |
> Stroller. |