ietf-dkim
[Top] [All Lists]

[ietf-dkim] OT: Return-Path considerations (was: "I sign everything" yes/no)

2006-11-24 07:39:20
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
and 3798.

Frank


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>