Hector Santos writes: > On 4/25/2015 11:34 AM, Stephen J. Turnbull wrote: > > > > My personal opinion is that, on the contrary, people are already way > > too quick to discard proposals simply because they involve changes to > > MUAs. Of course, the reality that this is an IETF WG, and what we can > > do that has effect with high probability is change wire protocols. > > MUA presentation is outside of our bailiwick, ...... > > Stephen, we (SSI) have the following MUA and/or interface points that > is still supported:
Knowing what your product *does* is useless to me, unless you provide it to one or more of the following: AOL, Yahoo!, GMail, Hotmail, and the Outlook family. I'm far more interesting in *rationale* (defined as "arguments more detailed than writing POLICY in all caps") *for design*. > Today, there are only two requirements in the RFC 2822/5322 format; > From: and Date: It was relaxed from RFC822 requiring the To: field as > well. > > Lets not assume that all systems are RFC x822/5322 based. The Internet is, and that's what we're here to discuss and improve, no? If the MDA/MUA functions transform the message, tracking the information that used to be in the header is their problem. But to the extent that MDAs and MUAs preserve and handle the RFC 822 format, some techniques we consider here may be appropriately recommended to MUA developers (eg, in a BCP), and may be useful in design of non- Internet message processors. > Also consider that RFC message overhead is getting whack, over > bloated and wasteful. Redundancy is the fundamental constituent of robustness. In any case, in my INBOX, the median size Internet message is about 20KB, of which about 4KB is header (20%). However because of spam and attachments (before saving and stripping attachments) header content of non-spam is less than 2%, on heavy spam days, well under 1%. By contrast, spam, unnecessary office attachments, and quote bloat probably account for an order of magnitude more "bloat" than headers. If this "header bloat" causes a real problem in processing, tell us about the real problem. > I have sysops who will pull the MIME and HTML and provide a pure > text transformation. If the special user has a Preserve MIME need, > a request a made to the operator who will decide to set it or not. > 3rd party developers have written WCX tools to help operators to > make it more as a default today. Obviously users of your product account for a tiny minority of Internet mail, then, as I personally don't know anybody who would consider "MIME is more of a default" as adequate for handling their mail streams.[1] Even my Emacs-MUA-using colleagues get pictures of their babies from their spouses and send them to the grandparents. > Lets not forget that the Receiver (including the Mediator receiver, > not just the end-user receiver) also benefits by reducing the > fraudulent mail and blocking them at the door. Its not about just > protecting the originator or the end-users. The problem I'm trying to solve at the moment is not that too little "bad" mail gets blocked (though that is still a problem). It's that current protocols block 100% of "good" mail of certain classes (where "class" is sufficiently detailed as to include the DMARC policies of Originator and Receiver). Perhaps others are more interested in blocking more bad mail than I am, but AFAICS DMARC has gone as far as possible in blocking bad mail based on author domain alignment (I really don't think Doug Otis's proposal to use Sender instead or in addition can help). I haven't seen any suggestions to improve bad mail blocking here, except for your advocacy of stricter "policy", but as a Mediator developer, I can't be happy about going in that direction without third-party authorization, and we don't have a consensus on that here, let alone uptake from DMARC participating Author Domains. _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
