ietf-smtp
[Top] [All Lists]

Re: Recap Issues 0b/21/25

2007-04-30 08:01:56

David F. Skoll <dfs(_at_)roaringpenguin(_dot_)com> wrote:

Tony Hansen wrote [suggested text]:

A server MAY attempt to verify the return
path before using its address for delivery notifications, but
methods of doing so are not defined here nor is any particular
method recommended at this time.

How do we reconcile that with:

... the protocol requires that a server
MUST accept responsibility for either delivering a
message or properly reporting the failure to do so.

If a server verifies the return path and decides not to use it, what
constitutes "...properly reporting the failure" to deliver a message?

   A good question -- well worth our time to discuss a bit, though I
doubt we'll come up with any text to include.

   First, I'd like to violate one of the rules here, by including some
actual data ;^(

   We run a number of mail-servers here, several of which apply the
same anti-spam rule and return a 5xy error including a reference to
a jlc.net webpage. I collected one week's data for that one rule:

    5xy responses sent: 368,074
     webpage accesses:        2

   (Actually, those two were from the same IP address, less than
five minutes apart.)

   I claim this data supports my contention that folks don't _use_
the NDNs that they get. (Yes, I know, the clients we gave that 5xy
to may not have delivered the actual text in the NDN they generated.)

   I believe any data we could collect involving "typical" users would
show the same trend: 99.9% of NDNs are not read. (What folks _do_,
in my experience, is call the intended recipient and complain, "your
spam filter is broken" -- if they do anything at all, that is...)

   This is why, BTW, I'd like to retreat from SHOULD to MAY on sending
NDNs: they accomplish almost nothing, and they annoy too many folks..

   Getting back to the question, "properly report" involves, at the
minimum, logging the incident so that it's _possible_ to reconstruct
what happened. I'd like to suggest forwarding those log entries to
the client you received the message from, but I suspect that exceeds
our charter. 

   Sending an NDN which has only one chance in a million of conveying
the right information shouldn't be touted as "properly reporting".
Log files with better persistence are far more useful.

   IMHO, we're going to have to settle for vague language on what to
do in the case of an error not detected during the SMTP session.

--
John Leslie <john(_at_)jlc(_dot_)net>