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