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
