Hi,
On Thu 05/Jun/2014 20:34:06 +0200 Doug Otis wrote:
On May 9, 2014, at 3:23 AM, Alessandro Vesely <vesely(_at_)tana(_dot_)it>
wrote:
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.
How can sending domains select the signature scheme? For example,
often there are other destinations cc'd.
An MTA can sign the message differently for different recipients. If
all recipients are trusted, there is no need to do so.
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.
Agreed. I added TPA-Labels to the picture I posted on the ietf list
on May 14. All three methods serve the same purpose, but they have
different pros and cons. Roughly, TPA-Labels can aggregate domains
into federations, so they seem to be better for well established
lists. Weak signatures provide for per-message control at the sender,
and are compatible with vanilla DKIM at the receiver. For redundancy,
a sender can apply both of them at the same time.
Good mailing lists are fairly keen at confirming subscriptions and
do not represent a source of abuse.
Confirming subscriptions is part of the "manual process" in the
picture. That seems to be the most difficult problem at this time.
DMARC reports can hardly be used to create a DB, IMHO. However, a
sender could use reports from trusted receivers to verify it (that's
the yellow question mark in the picture). Just mumbling...
If a spear-phishing problem is confronted, authorizations could
require an ORA header be added. An easy feature to add to this
scheme.
If the spear-phisher can authenticate, I don't see how a possibly
spoofed ORA can help the receiver.
Ale
list-db.gif
Description: GIF image
_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822
list-db.gif