[ On Tuesday, September 18, 2001 at 00:16:49 (+0100), Matthew Byng-Maddick wrote: ]
> Subject: Re: [Exim] Trying to compare HELO data with actual host info in a filter...
>
> Security is the wrong word, but knowing what you are supposed to and not
> supposed to do is kind of helpful.
No, "security policy" is exactly the right word.
Spam, and spammers, and especially those who try to abuse open relays,
are attempting to violate the security and integrity of my network when
they try to connect to my mailer.
If a mailer announces itself using a clearly incorrect name I can only
assume that there is either an error, or a fraud in progress. In either
case my only course of action, given my security policy, is to reject
the connection.
> > It's actually a lot better to refuse the connection instantly instead of
> > receiving a message and then later dropping the message in the bit bucket.
>
> Not quite:
> a) you don't know at the time they connect what their helo line is going
> to be.
I mean after the HELO/EHLO, obviously. You can't verify the correctness
of the HELO/EHLO parameter if you never receive it.
I do tend forget that some people reject the very TCP SMTP connections
sometimes. I hardly ever do that, unless mabye some mailer is abusing
every rational attempt I use to try to tell them they are not welcome
(in which case I use an IP-level filter to block any and all traffic
from their network).
> b) the only kind of error response you can give to a legitimately formatted
> helo line is a 421, in which case dropping the connection is legitimate.
No, that's asking for very big trouble. Many (not so well programmed)
mailers will immediately connect back again, and will continue doing so
for as much as an hour or more, and often will repeat this cycle again
and again after some intermediate period of inactivity. If you don't
have any delay to penalize such failed connections (i.e. before the 421
is issued) the effect can be very nearly a DoS against yourself!
It's also very inconsiderate to a legitimate sender. Their e-mail will
now sit in their mailer's queue until it either bounces after N days of
attempts, or until manual intervention is taken. Never return a 4xx
series response if your intent is to reject the message or the
connection. It will not work and it can only cause problems at both
ends.
Furthermore there's nothing in the SMTP protocol that restricts a server
to sending only the documented responses. Read Appendix E of RFC 821,
or section 4 of RFC 2821, and in particular this statement:
Consequently, a sender-SMTP MUST be prepared to handle codes not
specified in this document and MUST do so by interpreting the first
digit only.
> If you meant just dropping the connection straight, that's a very silly
> thing to do, and helps noone.
no, of course not.....
> Your alternative is to 550 at the RCPT TO:<...> stage (or the MAIL
> FROM:<...>)
Yes, but that's a poor alternative as it gives a misleading reason for
the drop (even with proper explanitory text in the response). Many
mailers screw up the explanation, or mis-classify the error.
The correct alternative is to send a 55x series error immediately in
response to the errant command, i.e. the HELO/EHLO greeting, and wait
for them to QUIT (or RSET and try again), as they must. If they respond
any other way then they get a "503 Bad squence of commands".
> > At least then a legitimate sender can be informed of a configuration
> > problem at their end and hopefully get it fixed.
>
> Like that'll happen.
It certainly does. I've been doing this for years now. It works
surprisingly well in fact, even with all the problems of poor DSN
handling in many mailers (MUAs and MTAs). Most people who are told of
configuration errors at their end are more than glad to fix them.
> I run something called SAUCE on my outward facing MX for colondot.net,
> this does basically that kind of thing. I end up having to put in exceptions
> for people I trust with broken mail systems, rather than managing to
> persuade people to fix them.
I never make any exceptions for problems that are not my own. If some
sender has a broken MTA or DNS configuration then they can fix it if
they want to send me e-mail.
In fact _most_ postmasters I've encountered who have had such errors in
their systems are (a) very glad to learn of them, and (b) very quick to
fix them. There are, of course, the odd few idiots who won't do
anything, and unfortunately they sometimes do get between a legitimate
sender and my mailer. Luckily most senders are able to choose alternate
service providers or find other means of communicating with me.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@???> <woods@???>
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>
