On Mon, Sep 17, 2001 at 08:25:10PM -0400, Greg A. Woods wrote:
[ > I wrote: ]
[ >> Greg wrote: ]
> > 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.
[snipped semantics]
We can argue this all day. :-)
> > > 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.
Your original thing didn't make this clear.
> 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
Well, people are stupid.
> 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).
Reasonable enough.
> > 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
Teergrube.
> 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!
I do, see above. I agree that this is potentially a bad thing, but on the
other hand it's the only valid response you can give to a correctly formatted
HELO.
> 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
Yes... and? Their mailers queue will probably send them status notifications
too.
> 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.
No. You *aren't* allowed to reject based on the HELO parameter. RFC1123
makes this clear. So does RFC821. (2821 is just a PROPOSED STANDARD, and
hence shouldn't be referred to).
> 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.
This is true, however, you should be aware of Jon Postel's:
"Be conservative in what you send and liberal in what you accept".
Reread the first part of that sentence. Several times.
This is kind of true, as long as you are using ESMTP and you've both agreed
on extensions, otherwise you should really be using the table of defined
responses in S4.3 of RFC821, or you are running a non-standards-compliant
mailer, and just as guilty as the other party.
> > If you meant just dropping the connection straight, that's a very silly
> > thing to do, and helps noone.
> no, of course not.....
Sorry, I should have made that clear, I meant:
>>> 220 status line
<<< HELO funny.domain
[TCP RST]
which I'm sure you still think is a bad idea.
> > 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.
That's their problem. Many mailers think that a 550 after an RCPT is
equivalent to a 4xx class response, and keep the message in their queue,
trying again. (this is after a particular brokenness some years ago with
MSExchange). Does this make it right? No. It's their problem.
> 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
Reread S4.3 of RFC821.
> 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".
RSET doesn't reset the HELO/EHLO command on most mailers I've seen. Exim
doesn't even give a 503 if you do a MAIL FROM first. (getting back on topic
:-)
I don't think you can define the behaviour of sending a 5xx class error at
HELO time, other than for a missing parameter. Should I retry, obviously
not, what should I put in the bounce?
> > > 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.
Oh? Most people I've seen just complain and whinge, and assume that
a) they have a right to send me email
b) that if every other mailer works and mine doesn't, then there's obviously
somethin wrong with mine rather than theirs...
I've also seen some *really* broken attempts at anti-spam prevention. I mean
if you're going to do it, you really *should* be RFC compliant, otherwise
who are you to be able to complain at their configuration errors.
One of the most fun I've seen is a particular SMTP filter that TCP RSTs the
connection after sending a 5xx response. That one was also configured to
reject MAIL FROM:<nobody@*> (not literal, but globbed). I thought that was
a pretty broken anti-spam rule and told them so. I did acknowledge, however
that it was their choice.
> > 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.
This attitude unfortunately doesn't work. Which is a pity. These days, rDNS
is seen as a "security risk", no, I'm not joking, and I require rDNS in
order to deliver mail to mbm@???. That and a HELO line that looks
up, a return-path that will deliver bounces, etc etc. I still end up having
to make exceptions. Often companies I want to buy things from have broken
mail setups. People I want to talk to don't necessarily have the leverage
to get things fixed, especially in the case of admins who are like the above.
(no, I'm not going to say which company was the most recent to do that, but
suffice to say they should know better...)
> 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
This may once have been true.
> 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.
You're obviously very lucky. See my earlier discussion on this list about
people who run mail systems, and tell me that you think it's still like
that.
MBM
--
Matthew Byng-Maddick <mbm@???> http://colondot.net/
