On 7/2/2013 10:11 AM, Murray S. Kucherawy wrote:
On Mon, Jul 1, 2013 at 12:24 PM, Michael Deutschmann <
michael(_at_)talamasca(_dot_)ocis(_dot_)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