----- 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