> On Jun 14, 2014, at 5:25 AM, Patrick Rauscher <[email protected]> wrote: > > Hey, > > On Fri, 2014-06-13 at 22:35 -0400, Hector Santos wrote: >>> Perhaps I'm oversimplifying, but it has seemed self-evident that you need a >>> single identifier that is displayed to the end user and 5322.From is the >>> only >>> identifier that even comes close to being the right one. > > (I don't have Scotts original mail here, so I reply to this. Sorry!) > Imho 5322.Sender is relevant too. Yes, MUAs usually don't respect this > Header (and it's used not very often :-( ), but most don't show > DKIM-Validation (which could be included together).
Some do have new display logic for the sender. However, unless you (the backend) have control of the mail reading process, both online and offline/offloaded, in general you don't, we can only be pretty confident of what would be displayed with the four basic messaging fields common in all communications as a common denominator: o Date o From o To o Subject In other words, if you were to start tomorrow to write a mail reader/writer, you must begin with the above for the minimum display rendering. Remember, not everything is or requires a mail network. It can be an online forum which many systems are heading back to (or just starting with successfully because they are not bogged down like many older established systems are where change is not always a luxury). You really have two sets of headers: the above messaging headers and networking headers. Networking control lines, as old FidoNet folks called them, only came into play when you connected a heterogenous network of hosting nodes. For internet mail format networking, the Sender, Reply-to, Return-Path, most of the trace lines, did not apply until you had a network. When you gated a network, generally, they would be use just to make sure you can respond back and they would be hidden, transparent to the user. Sometimes the user may only interested in them to go a different route, reply directly or have it travel via some path that was either less costly or more timely, i.e., network routing methods. Subject is not always filled, but is expected to be part of the message. Some MUAs enforce it, others don't. In fact, RFC 822 only required Date, From and To. RFC 2822/5322 relaxed it to only Date and From. Date can always be filled as the local or system post time. So at a minimum, via RFC 821 5321, if a client doesn't enter the headers during, depending on how strict the deployment is set at, it doesn't need them when receiving the DATA payload and can recreate the 822/5322 headers from the SMTP envelope fields: 5322.From <=== 5321.MAIL FROM 5322.Date <=== system timestamp 5322.To <=== 5321.RCPT TO And you really don't need to fill in the 5322.To because for local direct mail pointers, indexes, this is done using a different control/meta method/file/line from the 5321.RCPT TO lines. You don't rely on the 5322.To or cc to make direct mail references. > Also this allows Mailinglists to interact with DMARC/DKIM correctly > (hint hint) Operators will have philosophical differences with developers. Always have. In my product development experience, it is good to get practical functional operational guidelines established and bad when sound technical engineering progress is impeded. The ML needs to fit in with the mail network like everything does with the few known long time acceptable exceptions. DKIM did highlight the body integrity issues, not the 5322 headers. We don't want to add a broken 5322.From to the security exception list. -- Hector Santos http://www.santronics.com _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
