[Asrg] Meta channel, not bounces (was: Re: where the message originated)

Alessandro Vesely vesely at tana.it
Wed Jan 14 09:12:23 PST 2009


Can we draw any conclusions from that thread?

Rich Kulawiec wrote:
> 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.

599 Bounce to postmaster. What would be wrong if it existed? (I mean, 
besides how hard it would be to reliably introduce it now.)

> Among other things, "malicious" isn't universal.  And anti-virus software
> does not have a 0% FP rate.)

I agree it cannot be 0%, but better than 0.000001% is expected. See 
e.g. http://www.sophos.com/support/knowledgebase/article/35504.html. 
It is also false that any executable content is likely to be reported 
as infected: the same AV software is used to scan hard disks, looking 
at executables only. (I'm not saying the same reliability cannot be 
reached for phishing or spam, though.)

Chris Lewis wrote:
> Our experience, issuing 55x at levels of 250,000-1,300,000 per day since
> 1997 indicates exactly the reverse. [...] Silently dropping emails would
> mean that those dozen or so FPs would go unnoticed by anyone.

A dozen at those levels is more than 0.001%. It seems very poor. What 
AV/config do you use? Perhaps, at that percentage I would do the same. 
The reliability I experience reliefs me when I violate the SMTP 
protocol by dropping messages. Since I have to err, I try and minimize 
damages.

Curiously, some viruses (e.g. Netsky) directly produce a bounce. 
Possibly, their authors reasoned that since there are brain damaged 
MUAs that conceal the body of DSNs but not the attachments, an 
attachment in a DSN has better probabilities of being opened. As a 
matter of fact, some virus variants have been surviving autonomously 
for years, which suggests that that reasoning was correct.

Bounce addresses are extremely likely to be spoofed. Sending 
disinfected bounces is hardly an option. At any rate, even when it is 
not spoofed, the author of a message is not always the right recipient 
for a technical report. Besides malware, SPF or DKIM rejections are 
difficult to understand and impossible to fix for end users.

MTAs strive to only produce bounces for messages that they have 
accepted for relay from their legitimate users. However, in some cases 
that's not possible. Forwarding comes to mind. Also, rfc5321 mandates 
no AV filter, thus the much exemplified virus-relaying MTA is 
perfectly legal.

Why don't we have a meta channel for those cases? Some bounces should 
be sent to postmasters, who can then send more meaningful DSNs, 
possibly after seeking the relevant message-ID in their logs, and fix 
the problem. I don't think sending to <postmaster at example.com> would 
make much sense, there ought to be a better mechanism...



More information about the Asrg mailing list