On May 9, 2014, at 3:23 AM, Alessandro Vesely <vesely(_at_)tana(_dot_)it> wrote:
Hi SM,
On Thu 08/May/2014 19:59:19 +0200 S Moonesamy wrote:
At 03:06 07-05-2014, Alessandro Vesely wrote:
to "standardize" its syntax.[3] It seems to me that eliminating some
of such gratuitous changes is the solution to DMARC-for-MLs which
minimizes the alterations in MLM software. Are you sure it won't
work?
This mailing list breaks the DKIM Signature.
No, it doesn't. It broke elandsys' signature, but check tana's
signature on this message. (I send this to ietf-822 only, to avoid
any confusion.)
So it seems I could publish a strict DMARC policy right now, and cause
minimal disruptions. However, some verifiers (NetEase) consider
tana's h= inadequate, see "objection" below.
Gratuitous changes to a mailing list message is a matter of
opinion.
Well, not exactly.
For corrections, section 6.4 of RFC 5321 is rather clear that
submission servers MAY, while intermediate relays MUST NOT, apply
certain changes. So the range where opinions may vary is whether an
MLM is to be considered akin to submission servers or relays.
By /gratuitous/ changes, such as adding/removing double quote marks, I
mean unnecessary embellishments that were already disputable before
DKIM took root.
I suggest reading the past discussions first if you are interested
in trying to make it work.
Yes, much of this discussion was recited at the time of ADSP, for
example http://mipassoc.org/pipermail/ietf-dkim/2010q3/013829.html
The most relevant objection to weak signatures is why would domains so
concerned about security as to publish a strong policy weaken their
DKIM signatures? A solution is to do so for ML messages only.
To recap, assume a domain has a DB of (user, mailing list) pairs which
defines ML traffic. Messages to ML are then sent in separate SMTP
transactions and weakly signed. MLMs sign those messages in turn,
using strong signatures. Verifiers derive the validity of MLM domains
by comparing d= against To: or Cc: mailboxes.
Besides minor refinements, the major bar is to build that DB. I
proposed to do it manually for starting, and then find out how to
automate its maintenance.
Dear Alessandro,
How can sending domains select the signature scheme? For example, often there
are other destinations cc'd. Conveying an alignment exception method to all
parties is the intent behind TPA-Labels. This avoids the need to apply weak
signatures that can be maliciously replayed. After all, DKIM does not
constrain possible recipients. Good mailing lists are fairly keen at
confirming subscriptions and do not represent a source of abuse. If a
spear-phishing problem is confronted, authorizations could require an ORA
header be added. An easy feature to add to this scheme.
Regards,
Douglas Otis
_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822