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