Scott Kitterman wrote: > If the Mail From domain has a DKIM policy record that says it > signs mail, then that's an external source that is at least > somewhat more believable.
Okay, let's assume that the MAIL FROM somehow indicated "the domain in the RHS of the MAIL FROM publishes a DKIM SSP". The server could then get and cache this SSP. If that fails the indication was wrong (or there's an obscure DNS problem). >> why the same as the 2822-From ? > In order to know what policy record to look at. Before DATA two "sending" domains are in play, EHLO and the RHS of MAIL FROM. Or three if the client supports RFC 4405. Not necessarily related to the domain in a later 2822-From. I'm still trying to figure out what you're getting at. Let's say the client promised that a SSP for the MAIL FROM domain exists, the server got this policy, and accepts the MAIL FROM. In the DATA it might find mail with a different 2822-From, and that might be DKIM-signed or not. In that case an unrelated MAIL FROM SSP does not help. And if "the" 2822-From domain is the same as in the MAIL FROM the server already has an SSP, see above. We heard that this might be the case for about 80% of all mails. Is this so far what you have in mind ? I wonder why the DKIM- aware server doesn't use this approach always, even without any indication in the SMTP session. > Mail From and signing will usually be generated at the MSA, The one MSA I knew (in the MARID days :-) implementing RFC 2476 6.1 verified that my MUA used an appropriate MAIL FROM, it did not go so far as to _generate_ it. Another MSA I knew set both MAIL FROM and 2822-From no matter what my MUA said, but that's not directly covered by anything in 4409 (was 2476). JFTR, it's clear what you mean. > as long as the policy record is correct for the signing > domain, I don't think that matters. For proposals to signal DKIM support in the SMTP session it's relevant. The two MSAs mentioned above had separate "mailouts" behind them, sending mails to foreign MXs. Senders wishing to support such ideas have to upgrade their "mailouts", too, not only their MSAs. Frank _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
