Douglas Otis wrote:
DKIM is unrelated to the message envelope
True, more below.
Requiring the 2821.Rcpt To to match a 2822.To or CC header
field email-address is not practical.
Of course, anything not matched is by definition a BCC.
Any assumption that a DKIM signature can be used as a basis
for acceptance or rejection introduces very serious denial of
service issues.
It's THE job of SSP to change this. Or maybe ONE job, this
algorithm transition stuff is also relevant, but I don't care
where and how it's done (as long as Phil says that it's okay).
The DKIM signature does safely permit the following when a
signing domain has been designated by an email-address:
[...skipping annotation...]
- Safe DSNs based upon 2821.Mail Froms.
No, as you said above "DKIM is unrelated to the"..."envelope".
To avoid abusive DSNs to innocent bystanders you always need a
verified Return-Path. Minimally you've to trust that it's no
nonsense (e.g. if it came from a source where that's hopefully
guaranteed).
If you think that _DKIM_ (not the cases discussed in 4408+4409)
safely permits safe DSNs I'd like to know how that's supposed
to work. IMO it simply does not allow this, and that's no bug
or bad thing, it's a consequence of the "unrelated" (to SMTP).
There should be a general understanding of the futility and
perils using a DKIM signature as a sole basis of acceptance
or rejection.
If a policy makes 2822-compatible statements about signatures,
then using it isn't futile or perilous. Nobody's forced to
publish dangerous policies, nobody's forced to evaluate them,
this is a completely voluntary business, same idea as SPF (or
SenderID, modulo its known IAB-appeal IESG-note fine print).
Abuse MUST be handled by identifiers tracking the actual
sending agent.
Maybe, but that's not a "MUST" for SSP reqierements, it belongs
into another document like 2821bis or BASE.
What are the underlying security concerns related to some
email-address policy and how can security be generally
improved upon by this policy?
Isn't that already covered by the threats RFC ? For the "SSP
requirements" it would be a waste of time if it tries to list
all potential security considerations of a future SSP proper.
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html