On Mon, 17 Sep 2001, Greg A. Woods wrote:
> [ 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.
By all means you are within your right to do that with your own
equipment, even if it does violate RFC.
My main point was, that the number of cases where some (legitimate)
mailer is misconfigured, or their rDNS is incorrect (or even
nonexistant) is FAR more common than spam falling into this category.
>
> > > 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.
>
>
--
