On Saturday 10 October 2009 12:53:14 hector wrote:
(cut)
This occurred with the DKIM-DEV list I am subscribed to. I forget the
exact reasons but the end result is that my MDA began to reject my
copy of the DKIM-DEV list distributed mail I thought the sender was
white listed as I receiving mail fine in the past.
But something changed on either end and I received an automated final
warning notification that my subscription would be moved if I don't
response to the notification (click the url and confirm I am a real
person). It was odd the notification got thru but normal distribution
were rejected.
probably sent from the list domain rather than the author domain.
So I fixed that by adding more white listing rules for
this list sender.
Whitelisting on the scale of individual receivers is an inhibition to
adoption.
That got me thinking about RFC 5617 support as it was being
implementing as part of our SMTP level scripting filter language.
Out of the box, our inbound MTA will run the "DKIM SCRIPT" at the
SMTP level.
So imagine, if a resigned mail was received from mipassoc.org for a
author domain that happens to have a ADSP = "DISCARD" or "ALL", then
this would be a failed DKIM/ADSP transaction.
It was already troubling that a list server would not honor RFC 5617,
but now I saw how the list server can now begin to send notifications
to subscribers for rejected mail.
this is useful as at least in this case stuff didn't break silently. lucky I
guess.
So I see three possible mitigating options:
1) Update RFC 5617
1.a) All DKIM-BASE compliant receivers SHOULD supprt RFC 5617
support: +1
1.b) All DKIM Resigners MUST respect RFC 5617
support: +1
1.c) All receivers who support RFC 5617 MUST use post
message acception silent discarding of mail and not use a
SMTP level rejection to avoid bounce issues and mail list
subscription removals.
not sure.
In addition to subscription list removals this would cause silent failure to
ordinary sender to recipient communication that fails because of sender error
or intermediary content reformatting when a simple/simple canonicalisation.
It seems from your case above that automated removal isn't totally there so
perhaps it could be kept as is even if a few people get scared into
considering DKIM/list implications fully.
other options:
Receiver temp fails the messages and tells then recipient with a "whitelist
this if you want" option
keep as reject but use http://tools.ietf.org/html/draft-kucherawy-dkim-
reporting-05 to supplicant processing.
1.d) Standardize http://tools.ietf.org/html/draft-kucherawy-dkim-reporting-05
2) Extend RFC 5617 with an explicit 3rd party signing option.
2.a) add a dkim=3p option (which is what I assume you meant from previous
messages) informing the recipient that the sender isn't adverse that 3rd party
signers be accepted instead of the ADSP.
2.b)
Extending RFC 5617 to support Sender: as a author responsible party header
header to be checked in same way. Useful as many maillist already do this.
This has limited MUA visibility though Outlook does display this in a way to
avoid some spoofing attacks. Sender was standardized a long time ago so
encouraging MUA developers to make use of this by making this change could be
useful and perhaps a path of least resistance/maximum benefit.
Perhaps given the recipient filtering options may differ between between a
first party and a third party signature perhaps keeping this as a separate RFC
(also to be listed in 1.a) is needed like.....
4) DKIM Third-Party Authorization Label
pros:
* works for a number of explicit authorizations. In conjunction with dkim-
reporting could provide an automated way for senders to add third party
authorisations with little ambiguity about what the sender intent is.
cons:
* the scalability on large environments to include all mailing lists that
author domain use is a little fragile.
5) List Domain Signing Practices (LDSP)
A consideration that email lists, as defined by the domain in the List-ID tag
(RFC 2919) could be treated in the same way as ADSP
As Stephen Turnbull mentioned on the mailman-developers list recently which
was where this was derived from:
"Obviously the amount of trust you put in LDSP-
authenticated mail is much lower than that you put in ADSP-
authenticated mail. Still, in the current environment I'll take
any bonuses I can get, and as long as I behave, I suspect the big
ISPs would be willing to allow me to build up some cred."
pros:
* no action required on author domain
* promotes DKIM for list operators
* less whitelisting for recipients
* gives recipients domain reputation as a criteria
cons:
* acknowledges that List-ID's are spoofable and that 4) is probably an answer
to this before reputation is developed or where delivery is really important.
3) Deprecate RFC 5617
If list server developers or operators are not expected to
support or honor RFC 5617, then we SHOULD declare RFC 5617 has
as non interoperable with DKIM-BASE, deprecate it and remove
it from standard track.
From the sympa-dev, dkim-dev and mailman-developers comments I don't think
there will be any resistance in list server developers or operators honouring
RFC 5617 and will probably drop/reject dkim=all|discardable if signatures
fail.
Ideally, I think #1 is required if we are going to keep it. I think
[2a] should also be considered as well.
#1 DKIM-BASE strengthen: good enabler for all of the below to work
#1d DKIM reporting: to handle incidental failures
Resigner/Mail list benefits by Option number:
#4 DKIM Third-Party Authorization Label: good for explicit third party senders
of importance to the sender
#2a ADSP add dkim=3p: middle ground that is easy to deploy as a sender and
gives recipients the ability to not be so strict about ADSP filtering
dkim=all/discardable filtering
#2b ADSP add Sender as author agent: quick gain for list operators that DKIM
sign and recipients that choose to implement it.
#5 LDSP: quick gain for list operators that DKIM sign and have a domain
reputation, easy gain for ISP and large domain verifiers
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html