ietf-smtp
[Top] [All Lists]

Re: RFC2821bis-02 Issue 22: Requiring removal of extra return-path headers in 4.4

2007-04-22 18:48:07

Hector Santos wrote:

This changes CODE!!! My code!!

Pardon ?  Users of a server using your code certainly expect that
there is precisely one Return-Path, reflecting the MAIL FROM as
seen by the final delivery MTA.

I'd bet that your code already does this, or do you keep crappy
Return-Paths inserted by prior hops in the header ?  What would
users do with that, where "user" can be anything from a stupid
vacation script and other auto-responders up to gateways.

What does this have to to with SMTP?

SMTP specifies who, when. what, and how for the Return-Path.  In
RFC 2822 you also find that there's at most one Return-Path, not
more.

If RFC 3834 requires it, thats fine. But you don't need 3834
to create bounces.

It's needed to create other auto-responses:

| If the response is to be generated after delivery, and there is no
| Return-Path field in the subject message, there is an implementation
| or configuration error in the SMTP server that delivered the message
| or gatewayed the message outside of SMTP.  A Personal or Group
| responder SHOULD NOT deliver a response to any address other than
| that in the Return-Path field, even if the Return-Path field is
| missing.  It is better to fix the problem with the mail delivery
| system than to rely on heuristics to guess the appropriate
| destination of the response.  Such heuristics have been known to
| cause problems in the past.

Are we trying to nail that the MAIL FROM = reverse path = envelope
sender = return path = "bounces to" <shudder />  is "the real thing"
everywhere, or do we need to discuss this emulation known as "PRA" ?

Frank