Ian Eiloart wrote:
I think the long term solution would be for mailing list software to
stop mucking around with the message body, and for MUAs to work
better at exposing meta data added by lists (like the list-unsubscribe
header).
This is the sort of improved "Mail Integration" information that
should be in a MLM document.
I increasingly believe we (the mail industry) needs a "Mail
Integration" document similar to the RFC1123 document (I called the
Bible) that help put it all together for online hosting systems with
integrated Telnet, FTP and SMTP services. It was because of RFC1123
that helped RFC2822/RFC2821 get done. In fact RFC22821 updated RFC1123.
We need a new document that deals all the new modern Mail Integration
needs, and it can cover most and not exclusively:
- Traditional Email
- NNTP
- POP3
- IMAP
- Web Mail
- Mobile Mail
- List Servers, Mailing List
- MUA (offline and online)
- SUBMIT (PORT 587)
- Legacy Mail Issues
- The "New Rules" (i.e. PTR requirements, DISCARDING, etc)
- DKIM
- EAI, IDN
etc. One of the things that I got out of RFC1123 was the Hosting
Requirements under one bird eyes view. This new "Mail Integration
Hosting Requirements" document would do a similar thing to get the
consistent and persistent expected behavior in the new modern mail
network.
My guess is that if the top five MUAs and the top ten webmail services
were all to make good use of list-unsubscribe and list-id headers (and
perhaps others), then many list operators would not feel the need to
mess around with message bodies and subject lines.
In principle, passthru mail should not be tampered, but MLM list mail
are the industry accepted exception to this non-tampering tradition
and today (at least in the USA), it is CAN-SPAM legal requirement to
have a viewable OPT-OUT text shown to the user to satisfy the CAN-SPAM
"capitalistic" legal right provided to the VENDOR to due business with
users.
Nonetheless, today, the list operators already has the option to not
change the body, but I can see if and when it was a "BCP" that end
users will see unsubscribe information by their MUA based on the meta
data, then list software developers may not make it a default to set
text footers.
From my (developer, vendor) point of view, we need to cater to all
markets. So for example, these are our defaults when an list operator
prepares a new list (showing ones that could alter the mail)
[X] Add [List-Name] subject tag
[X] Allow Attachments
[_] Strip HMTL Content
[X] Use List Address for Reply-To
[X] Keep Original To: Addresses
[_] Add Body Header
[X] Add Body Footer
[X] Add LIST-* headers
I can see a change where we offer an option for a new mindset group of
list operator thinking with Keep vs Change feature:
(_) Keep Original Submission Integrity
[X] Add LIST-* headers
[_] Use List Address for Reply-To
(o) Mail Submission Change Options
[X] Add [List-Name] subject tag
[X] Allow Attachments
[_] Strip HMTL Content
[X] Use List Address for Reply-To
[X] Keep Original To: Addresses
[_] Add Body Header
[X] Add Body Footer
[X] Add LIST-* headers
But remember, when there is a "need to change" it also comes with the
idea did we do it right, the need to justify the change, the whys and
was all the key design issues taken into account. Just consider a
change request where we will now need to double (Keep vs Change) the
internal name space for options.
In other words, from my point of view, if we are doing this for DKIM,
then the DKIM spectrum of design requirements are considered as well.
I think, in this case, that means honoring originating signed
submissions and if thats the case, then in my engineering opinion, all
top level DKIM "Mail Integration" design aspects are considered as
well, including honoring ADSP:
[X] DKIM options
[X] Exclude ADSP restricted domains membership
[X] Reject ADSP restricted domain submissions
[X] Validate signatures
[X] Add Authentication-Results
[_] Sign Message [Click for Signer Options]
[X] Strip Original Signatures
In other words, when the DKIM (re)signing option is checked:
[X] Sign Message [Click for Signer Options]
then the exclusively mutual (radio) option is automatically unchecked.:
(_) Keep Original Submission Integrity
because it doesn't matter any more when the MLM is always (re)signing.
Anyway, IMV, what people need is insights and let them make their own
decisions based on their own needs, but overall, the same outcome in
all cases should be the intended goal.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html