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?"
I don't think that will be problem because if users start poking around in
the email headers and wondering about the meaning we'd already be in a load
of trouble even without an AR header. There are plenty of things there
already to confuse users. But this does play into what Douglas was talking
about in another thread - namely, that if the "meaning" of the AR result is
ever to be communicated to the user via the MUA these "results" need to be
carefully defined to distinguish between "authorized" and "authenticated"
etc. This is a tricky problem and I think the rendering to users via the
MUA issue is outside the scope of what our charter is likely to include.
But it's important. For the record, my MTA comes with a web based mail
client and when I display messages to users which are DK/DKIM verified I
show a "MDaemon has verified that this message came from <identity>" (where
identity is a little tricky to determine and is different in DKIM than DK).
Something like this is about as basic as you can get and do anything at all
I think. But, you're right, it's a possible source of user confusion if
we're not careful. The worst possible thing would be to vouch for a message
to a user in an MUA that turns out to be exploiting the system somehow.
How about when sender domains presumed to
be relaxed DKIM ready policies and without signed
messages? Is adding an AR appropiate here?
Yes, adding an AR header is appropriate but showing something assertive to
the user in the MUA is not (just my view).
Then a maybe a list of most "persistent" headers should
be defined?
That would probably be useful.
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.
You have to do the verification before any changes are made by your list
exploder or other processes. In my case, my SMTP engine passes the message
buffer to a DKIM verification function immediately after reception and
before passing it to the MTA or list exploder.
MTA ---> MDA sender verification process
That will work only if MTA and MDA don't alter the message. In my case they
do (MTA adds Return-Path, might strip some headers, change line-lengths,
etc) so my verification is done in this order:
--> SMTP --> verification --> MTA --> list exploder or final delivery -->
possibly resign and resend message
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.
It is very common that border MTA's are doing the SPF/AntiSpam/AntiVirus etc
checks these days and will alter messages prior to allowing them into the
internal mail network. So some change seems unavoidable. If so, the DKIM
verification must be performed here and results passed on in the AR header
in my view.
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
Yes, this is very common for list exploders - as is changing the subject
header to insert the name of the list. I handled this by resigning all list
mail because I know it's going to get changed. I don't see another solution
in my case. This would be functionally equivalent to a list exploder
changing the message without resigning and then forwarding the message on to
a border MTA that did the signing there. Either way works and is common
practice out there.
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
Yes, I've experienced this too. All our customer support lists are set to
reply back to the list (thus all list mail here gets changed and therefore
needs to be resigned).
--
Arvel