ietf
[Top] [All Lists]

Re: TMDA backscatter

2007-10-09 19:56:02
Douglas Otis wrote:

On Oct 9, 2007, at 1:52 PM, Keith Moore wrote:

Returned message content in DSNs is often essential information for
debugging of mail system problems.   Blindly insisting that DSNs
should not return subject message content is shortsighted.  We have
already crippled the mail system too much as the result of naive and
shortsighted spam countermeasures.

The recommendation was to conform to requirements of RFC3464, but
could have been a bit more explicit in what was meant by original
content.  The concern is the abuse of DSNs as an indirect content
delivery mechanism.   Including original content runs a much greater
risk that any DSN then becomes blocked or dropped.  A more difficult
problem to solve occurs when no DSN is found after a message delivery
fails for some reason.  Less is more in terms of what should be
included of original message content.
Probably the biggest architectural problem with Internet email is that
errors are not reliably reported to either the sender of the subject
message or the party that is able to fix the problem.  DSNs didn't
change that, they just attempted to encourage a more uniform reporting
format.
[details deleted]

Is this what you would like to see in a DSN?
I'd like to see as much information as possible that has a bearing on
why the message delivery failed.  So if the error is "recipient not
found" or some such, then it might be acceptable to include only the
header of the subject message.  But if the error has something to do
with the content (like a media conversion error), then it's useful if
that content is returned so that it becomes possible to analyze why the
error occurred.

Of course it does little good to return a DSN to someone whose mail
address was forged by a spammer.   But to solve that problem without
impairing the reliability of mail delivery reporting, an MTA needs a
reliable way of knowing whether a particular return-path is correct.  
(where "reliable" includes being reasonably immune to replay attacks)

Keith

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>