On 4 Sep 2009, at 21:49, Alan McKinnon wrote:
On Friday 04 September 2009 17:23:15 Stroller wrote:
...
Every other solution out there has this one little problem that
people seem to
ignore.
Per RFC, if you accept the connection and the mail, you will deliver
it.
That's what it says. It also says this since days long before spam
problems,
but still. We all conveniently ignore this if we are talking about
what *we*
consider spam, and by "we" I mean "everyone who cares to take an
interest
except the actual recipient".
... Yet we accepted the mail implying that we will deliver it...
I don't think it's necessary to break RFC if you reject based on a
bogus HELO. The connection is initiated, but you do not get as far as
accepting the mail.
Instantly, 85% of the problem goes
away, and I have numbers to prove it.
85% of the problem goes away if you use Spamhaus, and that doesn't
require you to discard legitimate email.
And why is a user on a DSL range running a mail server anyway?
Personally, from my own point of view, it's so that I can see clearly
that a message has been delivered.
EG:
Sep 1 18:42:22 compaq postfix/smtp[6121]: A66A2137D25: to=<[email protected]
>, relay=mx1.mail.eu.yahoo.com[217.12.11.64], delay=2, status=sent
(250 ok dirdel)
I get complaints ALL the time from my customers, "oh, my brother /
mother / customer / supplier says they sent me an email and I never
received it". The only way I can debug this is to send them test
messages (sometimes daily) and tell them to let me know if they don't
arrive.
If a customer comes to you with a log entry that looks like the above,
referring to your server's hostname & IP, complaining the message was
never delivered, then you can, reluctantly, look in the problem,
grepping for A66A2137D25.
If the customer comes to you with a log entry like the above with
relay=smtp.my-isp.com then your response will be "oh, we probably
never got the message from your ISP". I presumably can log a support
issue with my ISP & expect them to come up with the log of the message
being delivered to your servers, but it's simply easier if I can debug
non-deliveries myself.
The vast
overwhelming majority of them are Windows zombies!
Which are easily filtered by checking their HELO resolves to an
independent domain. Or am I missing something here?
The remainder of those you're inefficiently filtering are Linux
enthusiasts running Postfix on their Gentoo boxes.
And finally, my mail servers are mine and I make decisions about
them, not
someone else.
Sure, but you're making unilateral decisions about the validity of
emails on behalf of your customers. And around here the customer comes
first.
If Bob wants to send Alice an email, he shouldn't have to reconfigure
his email server because Fred, the systems administrator at Alice's
ISP, is being a knob about things.
You may be the exception, having a narrow pipe and being unable to
afford the Spamhaus / DNS lookups to filter spambots in efficient
ways. Most systems administrators using this policy are unable to
justify the decision.
Best policy is to stipulate in the ISP's terms of service that you
will not
accept inbound mail connections from range you feel you cannot trust
and users
must use their ISPs mail relay instead.
You certainly won't get me subscribing to your service.
Stroller.
