[Asrg] where the message originated

[David Wilson]

On Tue, 2009-01-13 at 15:36 -0500, Rich Kulawiec wrote:
> On Tue, Jan 13, 2009 at 06:17:53PM +0000, David Wilson wrote:
> > If by "reject" you mean "give a 5xx response to the data from the SMTP
> > client, the problem with that is that, as previously discussed, the SMTP
> > client server may generate a DSN or similar which returns the infected
> > message. It does not know that the reason for non-delivery was the
> > suspect message content. You do. So the only safe responses are:
> > - discard the message (i.e. accept it over SMTP and then throw it away
> > with no further processing, apart from possible archiving).
> > - send a DSN or similar which suppresses return of content.
> 
> I've got serious problems with both of those.
> 
> In the first case, you're telling the sending server one thing and
> doing another.  I don't think that's a good idea on two levels:
> at a philosophical level, this seems like a bad way to run an Internet.
> At a practical level, doing so fails to alert the sending site that
> they may have a problem.  (Yes, I'm presuming that they're paying
> attention to their own logs...or that they will be more inclined to
> do so when they notice 86,000 5xx error messages in them.)
> 
> In the second case, generating DSNs is a bad idea in general [1],
> but it's a REALLY bad idea as a response to spam/virus messages.
> 
> Look, I understand the motivation, and it's very noble, but it's
> also pointless.  A hypothetical virus relying on this method of
> propagation will also have many other -- many other SIMPLER --
> ways of delivering itself to the very same targets.  The best that
> anyone external can do is (a) don't propagate the problem further
> (b) communicate via appropriate use of SMTP that there's a problem
> and (c) don't make the problem worse or more complicated or more obscure.
> 
> ---Rsk
> 
> [1] It's not that hard to engineer mail architectures -- including
> distributed and multi-tier architectures -- that always reject and
> never bounce.  Yes, there are always edge cases to be dealt with,
> but making them exceptions and not the rule makes it easier to
> then minimize the occurence/duration of those exceptions.

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.

(We are not talking about spam here, which is a different case, we are
talking about infected messages.)