Re: TMDA backscatter

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]