[ietf-dkim] OT: Return-Path considerations (was: "I sign
nobody at xyzzy.claranet.de
Fri Nov 24 06:15:53 PST 2006
Hector Santos wrote:
> The SPECS only require its for BOUNCE purposes in POST SMTP delivery
> checks and no other reason. Once thats done, you don't need it - not
> for SMTP or POP3 or IMAP purposes.
I can't recall how often I've posted the relevant part of RFC 3834 in
the last 30 months. The auto-reply stuff - it already got a normative
reference from the SIEVE-vacation RFC (or maybe it's still a draft, or
an approved draft waiting for its number):
| 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.
It's also used in all kinds of DSNs (not only non-delivery reports),
but as you said that's still within SMTP. It is also used for MDNs,
that's post-SMTP, see RFC 3798:
| MDNs SHOULD NOT be sent automatically if the address in the
| Disposition-Notification-To header differs from the address in the
| Return-Path header (see [RFC-MSGFMT]).
> the reality is that is not guarantee AFTER the delivery status has
> been determine and the message saved, gated, fido, news or not.
This isn't true. Don't let some MS calendar software behind their
emulation of groupware muddy the waters, this calendar software is
nice and popular, but no serious Internet MUA. I can't tell if they
fixed this after 2003, I only know Outlook versions older than 3834
More information about the ietf-dkim