----- Original Message -----
From: "Arvel Hathcock" <arvel(_at_)altn(_dot_)com>
I predict "fun time" running this "stripping" by ietf-smtp and ietf-822
folks (especialy as Authentication-Results is defined similar to trace
fields)...
Bring it on. I'm always ready for "fun time".
Well, the problem I am concern with is a new social engineering phishing
category of presumed higher intelligence. I am already seeing an increase
new of yahoo.com based non-signed phishing email transactions.
Are companies going to have to add new support procedures to handle confused
users?
"I see this AR and I am not sure what how I interpret this?"
How about when sender domains presumed to be relaxed DKIM ready policies and
without signed messages? Is adding an AR appropiate here?
How about expiration related issues of relaxed neutral DKIM policies?
Based on SPF relaxed policy experience, MTAs are not going to tolorate an
infinite abuse of neutral results and as predicted, this is exactly what is
already happening. There is already extended SPF implementations that limit
the usage of neutral or relaxed SPF policies. I predict the same will
happen with DKIM.
RFC 2821 section 4.4 states this:
....
Therefore, since the specifics of the Return-Path header provide
documentation whereby it is reasonable to assume that it could be
stripped we should recommend against it's inclusion in the
signature calculation.
Absolutely, the Return-Path is basically an temporary header to assist a
router and/or gateway in preparing the route/relay and/or bounce and it will
only be added if the payload is going accepted in the first place.
If the payload is deemed by the router for a local mailbox, most systems
will stripped before final storage simply because it isn't needed anymore.
However, I am seeing more instances in recent years of it being retained by
some final storage servers.
If the payload is going to be routed, it is stripped and used for the next
route session x821.MAIL FROM for one basic reason only:
Maintaining a persistent return path and the remote
MTA receiver will follow the same logic and add one
itself per specification.
The sender MTA is being more "considerate" of how the receiver MTA is
expected to behave.
So I agree and I don't think the Return-Path is a good candidate for
signing.
However, maybe added to the DKIM-Signature: record as a new tag? How can
Sender: play a role here? I am just not sure if its worth it.
We can punt this and a thousands other currently unknown weird signature
breaking issues with the simple statement "don't sign headers likely to be
changed, removed, replaced etc because if you do, you just hosed the
system.".
Then a maybe a list of most "persistent" headers should be defined?
I see from your DKIM ready message, you are using:
h=DomainKey-Signature: Received:
Message-ID:From:To:References:Subject:Date:MIME-Version:
Content-Type:Content-Transfer-Encoding:Reply-To;
Off the top of my head, the odds for "changes" increase as follows
0 Received: first hop should not change
0 Message-ID: Should not change
0 Date: Should not change
0 From: Should not change
1 Subject: Should not change, but some might
1 References: Maybe gates (news) might remove this
2 To: list could change this for target
2 Reply-To: list could change this to help MUA
3 MIME-Version: HTML strippers might rename this
4 Content-Type: HTML strippers will rename this
4 Content-Transfer-Encoding: HTML strippers will rename this
A good example was seeing a customer today using his yahoo.com account
sending DK signed email to our support list which is customized to:
- strip mixed text/html content parts
- strip attachments
- set the reply-to address as the list address
In regards to the verification, am I still thinking how or "when" this is
best done? I don't think changing our list server is the address.
In other words, I don't see this as an issue in the sense that the most
important consideration here (in my view) is the:
MTA ---> MDA sender verification process
For a mailing list, in my technical view, the MTA/MDA process is completed.
We have a final destination storage for an agent that might do whatever it
pleases (technically and legally) as opposed to passthru (routed, relay)
mail where there is more technical (and legal) issues regarding tampering
and maintaining mail content integrity.
In other words, maybe the passthru system should not be involved in incoming
payload verification nor any router outbound signing (as you indicated your
Server A outbound system is doing for all outbound mail).
Why?
Since routing or relaying or forwarding already requires a level of BCP
sender authorization by the MTA server, the optimal backward consideration
is to leave the passthru mail (payload) alone, with the normal exceptions
standard 2821 consideraitons reception of mail (i.e., Received:,
Return-Path)
Anyway, most networks operate in a "Thou shall not tamper or screw around
with passthru mail!" and I don't see why DKIM should even try to alter
this decades old standard mode of mail transport operations.
Final destination email is the key issue here I think. Mailing list
expansion, in my view, represents a different or new level of verification.
How do you deal with Sender? How about From, Reply-To, To?
Is there special RFC text somewhere stating conditions under which these
headers must be stripped from emails?
I don't see an issue with Sender and From: but Reply-To and To: might be
changed.
As I indicated above, there are list servers who do offer the administrator
the option to force:
Reply-To: list-address
Reason:
The standard MUA design interface (ergonomics) is by far to offer two basic
replay options:
Reply to Sender (REPLY button)
Reply to All (REPLY ALL button)
The default MUA RFC x2822 reply behavior is:
REPLY action:
To: <-- Reply-To:|From:
REPLY ALL action:
To: <-- Reply-To:|From: plus To: plus cc:
To solve "layman" user issues of performing a natural REPLY, the Reply-To:
is set list address in order for the user to respond back to the list.
Today, for systems that do not do this, a normal REPLY goes just to the
sender. The user has to be aware that to reply to the list, he has to use
the REPLY ALL option to get the list address. The considerate user will
remove the redundant addresses to avoid sending duplicate off-list direct
email.
I can tell you from customer support experience that when recently turned
off this option in our support list, many customers started to scream
bloody hell about getting duplicate emails and also getting direct email
only when in fact, the sender really just wanted to reply to the list, not
go off-list. So we turned it back on due to customer demand.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com