On 7/2/2013 10:11 AM, Murray S. Kucherawy wrote: > On Mon, Jul 1, 2013 at 12:24 PM, Michael Deutschmann < > mich...@talamasca.ocis.net> wrote: > >> On Mon, 1 Jul 2013, Alessandro Vesely wrote: >>> Well, not really. MAIL FROM: is only visible after delivery, so to >>> avoid dangling signatures one should store its value in some other >>> header field or... in the i= tag. >> >> ITYM "only visible *before* delivery" >> > > He means "after".
Actually, I believe he meant BEFORE. It (old school UUCP/SLIP "From " and SMTP "Return-Path:") can be pulled/stripped once the status of delivery is determined (i.e. the user exist) at the MDA and the backend stores the mail for user online NON-RFC based mail reading or NON-RFC and RFC based pickup. At that point, "From " and/or "Return-Path:" have no real remaining value for the transport - it has ended. In fact, the only real reason to keep RFC headers is for MIME rendering. But overall, you only need four key headers for multiple mail network/systems display rendering, including non-RFC: From: To: Date: Subject: For a network, a Reply-To: needs to be considered, otherwise useless for local communications. I guess overall, don't depend on RFCs after the transport is completed. Not every system is going to use RFC formats across the aboard from end to end and if a RFC mail protocol is dependent on end to end RFC persistency, either it won't work very well or not everyone is going to use it or use it as much as they can within their mail framework. Transformed with the body to a backend storage format, attachments extracted and stored separately, MIME/HTML rendering desires is the only reason RFC storage is used. A local-only mail site certainly don't need all the RFC storage overhead and processing necessary. Just consider the current most used "BBS" today - facebook. No RFC required. While I won't be surprise it is used an RFC storage format, it doesn't need it from a design standpoint. You only need the above field fields plus a body. For the Facebook private email communications, of course, some level of RFCs is at its gateway, but I will not be surprise if its goes into a transformation at the FaceBook gateway so any DKIM calculations need to be done at the transport, in IMO. Once received, a converter can take the key items necessary for storage to convey whatever ones want to convey. Keep in mind one reason for using RFC is that it may allow a mail system growth HOWEVER for each new thing, it adds more complex overhead processing and then you have to make sure it is all integrated correctly. What I mean is that a SQL or fixed mail header block containing a field "DKIM-Status" is far more efficient than having to keep the RFC headers around to repeat the calculations. -- HLS _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html