On Tue, Jan 13, 2009 at 10:38:02PM +0000, David Wilson wrote:
I'm not sure what you are saying should be done. If you reject from an
SMTP MTA (not a submitting UA) using a 5xx response, what is that MTA
going to do: generate some kind of non-delivery message. Normally, that
includes the message which was non-delivered, which the rejecting MTA
knows to be malicious. In order to prevent that, we need a status code
which means "I am not receiving this message because it has a content
which is dangerous". SMTP does not have such a status code.
Yes, I know. (And while I recognize that having such a status code
might help solve some problems, it would also open others. Among other
things, "malicious" isn't universal. And anti-virus software does not
have a 0% FP rate.)
What I'm saying is that the recipient MTA should just 5XX the message
and hang up. [1] That's all it can do without either (a) making the problem
worse and/or (b) redirecting the problem and/or (c) doing something
very broken like claiming to accept a message and then /dev/null'ing it.
There's no way to "fix" the presenting MTA, if we agree for the sake
of argument that it's broken. There's not even any way, with the limited
information available during the SMTP conversation, to figure out *how*
it's broken. Maybe it's an open relay; maybe it's not but is relaying
a virus from an already-infected user; maybe it itself is infected;
maybe a kazillion other things.
So the best course of action is that which contains the damage, doesn't
break anything else, minimizes SMTP traffic: 5XX it and move on. There's
no way to know what the consequences will be on the presenting side --
maybe none, maybe some, maybe a lot -- so there's no point in guessing.
At least the 5XX gives the presenting side a "heads up", if they're
paying attention, that something's amiss.
---Rsk
[1] If the problem repeats incessantly or rapidly, maybe 4XX'ing
everything for a while would be in order. In some cases, refusing
the incoming connection might be appropriate.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg