ietf-mailsig
[Top] [All Lists]

Re: DKIM - Header Fields

2005-07-20 08:36:20


On Tue, 19 Jul 2005, Hector Santos wrote:

0 Received:                    first hop should not change
0 Message-ID:                  Should not change
0 Date:                        Should not change
0 From:                        Should not change

From can get changed by some remailers but its very very very rare

1 Subject:                     Should not change, but some might

Gets changed by majority of mail lists

1 References:                  Maybe gates (news) might remove this

Rarely changes and news gateways are outside our scope of work

2 To:                          list could change this for target

Some mail lists change this but not all

2 Reply-To:                    list could change this to help MUA

Some mail lists change this but not all

3 MIME-Version:                HTML strippers might rename this
4 Content-Type:                HTML strippers will rename this

Some mail list may change it if they repack the message

4 Content-Transfer-Encoding:   HTML strippers will rename this

Can change more often then just Content-Type as transfer-encoding is
by design something for transfer agent to work with

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

By this you mean if text/plain was present, and text/html was there in
common multipart/alternative, right?

   - strip attachments
   - set the reply-to address as the list address

BTW - DKIM can not deal with stripping of data at al (META-Signatures technology can however with multiple EDigest).

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

I agree.

For a mailing list, in my technical view, the MTA/MDA process is completed

Here I don't agree. I view mail list as intermediate processing and email
redirection agent.

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.

Sender gets changed by mail lists. In some cases Sender maybe changed by
email proxy close to sender origin. From is rarely changed on the other
hand.

Reply-To and To gets changed less often then Sender.

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.

Haven't seen too many "considered" users.... (of course I'm also one of
less "considerate" and rarely remove additional addresses in list reply)

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.

Not surprised.

--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net


<Prev in Thread] Current Thread [Next in Thread>