Re: rfc2821bis-03 Issue 32: "MUST take responsibility"

On 2007-04-26 11:19:32 -0400, David F. Skoll wrote:
> Hector Santos wrote:
> > There is no server notification "message" requirement for NULL return
> > paths.  That would be definitely be a server implementation (feature)
> > concept.
> OK.  I forgot that.  How about just this:
>
>     If the original message has a non-null return-path, then a
>     proper failure report MUST consist of a notification to the
>     sender of the message.
I'm a bit uneasy about the "MUST" here. 

There are two concepts of "sender":

1) The entity responsible for sending the message (the "real sender")

2) The entity indicated by the reverse-path in the MAIL command (the
   "alleged sender")

In general, an MTA which just accepted a message from another MTA has no
way of reliably determining the real sender and has to assume that the
alleged sender is identical with the real sender.

Of course we know that this assumption is often not true.

And while I think that an MTA should make every effort to determine
whether it can deliver the message before taking responsibility for it,
I concede that there are situations where the MTA can only determine
that it won't be able (or willing) to deliver the message AND that the
reverse-path is very likely to be forged after it has accepted the
message. In that case I believe it is better to silently drop the
message than to send a NDN to an entity which is almost certainly not
the real sender.

Therefore I think that should only be a SHOULD, not a MUST. I'm not too
happy with just changing MUST to SHOULD, though. Maybe a longer
discussion of the alternatives is in order.

        hp

-- 
   _  | Peter J. Holzer    | I know I'd be respectful of a pirate 
|_|_) | Sysadmin WSR       | with an emu on his shoulder.
| |   | hjp(_at_)hjp(_dot_)at         |
__/   | http://www.hjp.at/ |    -- Sam in "Freefall"

signature.asc
Description: Digital signature