MH Michael Hammer (5304) wrote:
How does a 3rd party signing a message change the intent of the author
of a message? One might argue that breaking the original signature does
that. My response would be to then avoid breaking the original
signature.
But list servers will naturally do break the message, dkim signed or
not. no?
I want to minimize issues when adding DKIM considerations to our list
server - not create more issues. Today, there is a common practice
with MLS altering one, all or more of the following:
- Optional Subject List Name Tags, i.e. [ietf-dkim] subject
- Reply-To: change to accommodate the current UI of most
RFC based mail readers with its default button/menu logic:
[ Reply ] - Uses Reply-To or From:
[ Reply to All ] - Uses all Originator fields
To:, Cc: Reply-To
Some MLS (like ours) will offer a list option to change
the Reply-To so that the natural behavior of a user clicking
Reply will go back to the list and not a direct email to
the author of the message.
- footers and (headers), with the footers the most common
- Stripping based on content restrictions (no attachments,
no html content-types), etc.
The question becomes under what conditions should a MLS-based DKIM
signing take place to eliminate downlinks DKIM verification issues,
including damages to domain reputation.
The only thing I can see if to remove all original domain
considerations. With no Policy, author domains are less important.
One of the arguments put forward supporting the DKIM effort was that
unlike SPF it is not hop dependent.
True, but SPF does have RFC 4405 (SUBMITTER) to help address hop
transition Domain::IP association issues.
For DKIM, the irony is that it might have similar issues from the
standpoint of the route path and who was last (re)signed.
MUA -> | MSA/MTA/SIGNS | -> MTA/BREAKS
ROUTE #1 -> MTA/RESIGNS -> MTA -> MDA
ROUTE #2 -> MTA -> MDA
We had a support incident last year where the MTA took one of two
routes (for some reason). Depending on the route, a Date was
added to the original message (because it was missing), the other
did not. When the messages reached the customers server (our product),
the customer was complaining about different mail reader display dates.
This proves its possible that is a DKIM ignorants MTAs can have two or
more different routes for distribution. So just like SPF, depending
on the route it takes, things can break. Does the new MTAs now need
to learn to use a special route for DKIM messages only? One with
minimum hops?
Here's an idea:
Can receivers help the process by adding a special MX record
specifically for DKIM reception to help MTA take a direct path? Maybe
special by sub-domain? mx1-dkim-receptor.domain.com
I guess the overall issue is why should any MTA, including a list
server auto-correct a broken message and it is safer to only consider
resigning when it going to break a valid dkim message?
--
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html