ietf-822
[Top] [All Lists]

Re: Experiment #2 with multiple Reference headers (was References with multipl

2005-01-17 09:56:03

Lists that set Sender are broken anyway, because (as you point out)
this obscures who originally sent the message.  Of course, there are
exceptions - such as digests and anonymous lists - but they're rare.

I agree with you, but this is not what current practice is and practicly
all mail lists do add Sender header (including this ietf-822 list).

...and it needs to be stopped, because now the pseudo-authentication anti-spam systems want to depend on that behavior, which will only make mail even less reliable than it is now.

And I think this may even have been documented, I seem to remember reference
in some RFC that Sender header should be added by mail lists.

maybe. I don't remember having seen it. if you can find the reference please let us know.

In general, if software thinks it needs to rename a field that's
already there, there's usually something fundamentally wrong with the
_intent_ of that software.   The primary purpose of submission agents,
MTAs, lists, and recipient MUAs is to _preserve_ the original message,
not to alter it.

Well, the primary purpose of any MTS is to delivery email or rather in
current world (with spam all around) it is to delivery email that recipient would like to see. Header data are part of toolset used by MUAs and MTAs
as means of identifying properties of that messages and how it its been
(or being) delivered. Addition of information to identify that message
passed through email list and identification of mail list email address
seems quite appropriate and such data is usefull for the user.

we have List-* fields for that purpose.

What is not ok is loss of data, such as original Sender or in fact data
about previous mail lists if message passed through more then one and
then List-* headers are all overridden.

well, arguably List-* fields tell the recipient about the list from which he received the message.

and rfc2369 says:
Mail list processors should not allow any user-originated list header fields to pass through to their lists, lest they confuse the user and
   have the potential to create security problems.

which sort of implies that List-* fields from earlier lists are going to be deleted, because the list processor has no way of knowing the difference between "user-originated" fields and fields added by earlier lists.

But in the mean time, you're welcome to comment on the following:
http://www.elan.net/~william/emailsecurity/draft-leibzon- emailredirection-traceheaders-00.txt

thanks.  it will probably be a week or three, but I'll look at it.

Keith


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