From: Alex van den Bogaerdt
[mailto:alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net]
Sent: Tuesday, November 01, 2005 1:44 PM
Hi,
Whomever is managing this list: it modifies RFC822 "To:". The same
happened to spf-help, seems some kind of update is responsible for
this change.
Result:
- It looks as if mail is sent to me in stead of the list
- reply-to-list doesn't work anymore
A rather weird and inconvenient default setting if you ask me.
Yes, it is inconvenient. I just changed my filtering rules to use the
List-ID: header instead of To:, but not all MUA's can do this. I second
the problem with the List-Post: header being missing, which many MUA's
use for reply-to-list.
While we're on the subject of how a mailing list ought to deal with 822
headers, the list is redistributing an original submission. It is a
common practice (abuse?) to set Sender: to the list owner address.
Perhaps because a popular MUA from an unpopular software company then
displays
From: Alex van den Bogaerdt on behalf of SPF-discuss
I don't really know why this practice developed. Based on the RFC's,
one could argue that a list should instead set Resent-From: to the list
owner address. Though no MUA known to man displays this by default, and
the most common MUA's can't display it at all (except when viewing all
headers for one specific message), that is arguably the most
RFC-compliant way for a list to behave. The Sender: header is really
meant for an original submission by one party on behalf of one or more
original authors. While RFC2821/2 are unfortunately silent on what
mailing lists should do in this regard (a politically astute decision),
they do categorically state that mailing lists operate by redistribution
as opposed to alias exploding and thus are _not_ considered forwarders.
The list reinjects received messages into the transport environment, and
since it isn't forwarding, it must be resending. That's the best I can
do after a careful rereading of RFC(2)821/2 along with 1123.
This is the technical argument. However, that has to be counterbalanced
by the weight of existing practice, which some consider a de facto
standard. This is something that reasonable people can disagree on. It
is possible for a de facto standard to be different from the RFC's and
be the actual standard, even if we don't like the way it came into
being. IETF standards are voluntary, and if people decide to implement
something else en masse, well, you can't force them to do it your way.
Personally, I'm still undecided if the weight of current practice forms
a de facto standard that renders the RFC-compliant method irrelevant.
Any opinions?
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com