Dave Crocker wrote:
Folks,
I'm not sure whether this fits into SSP or not, since it does not seem
to require that a record be published. However...
It seems to me that if a message has a DKIM signature and the signing
domain matches the domain in the rfc2821.MailFrom command, then it is
safe to generate a bounce message to that address.
By 'safe' I mean that one can be confident that the mail will not go to
an unwitting victim of a spoofed address.
Am I missing something?
Two things:
1) Of course, 2821.MAIL FROM is not 2822.FROM,
2) BOUNCE is for non-deliverables, not "non authenticated messages."
We should be careful to mix bounce semantics.
We have the possible technical logic:
A - Message Deliverable Status (1, 0)
B - Message Authentication Status (1, 0, ?)
That gives you 6 possible scenarios:
A1, B1 --> PERFECT WORLD!
A1, B0 --> DROP, BOUNCE DOES NOT APPLY
A1, B? --> DROP MAYBE?, BOUNCE DOES NOT APPLY
A0, B1 --> DKIM DOES NOT APPLY, MSG NOT DELIVERABLE -> BOUNCE
A0, B0 --> DKIM DOES NOT APPLY, MSG NOT DELIVERABLE -> BOUNCE
A0, B? --> DKIM DOES NOT APPLY, MSG NOT DELIVERABLE -> BOUNCE
Maybe you thinking DKIM STATUS REPORTING feedback concept?
In my book, RFC2822 is a 2nd stage consideration. 2821 comes first and
for systems doing 2821 level successful checks, the BOUNCE is considered
"USEABLE." In other words, in order to avoid bounce attacks, the 2821
system has to do its checks outside of 2822 considerations such as DKIM.
This might include SSP checking before the message is ACCEPTED at the
DATA level, and the only type of SSP you should check for is for your
basic SSP/DKIM violations as described in DSAP.
- NO-MAIL EXPECTATION
- NO SIGNATURE EXPECTED/BUT MSG IS SIGNED
- SIGNATURE EXPECTED/BUT MSG IS NOT SIGNED
DKIM validation is not required.
This is what we are doing in our products, and in fact, are currently
adding the logic to our List Server where it does some rudimentary
subscription DKIM POLICY checks.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html