Steve Atkins wrote:
Given the DKIM sig and the "Return" SSP record, I'll generate it since
the return address domain has said it's valid.
Wouldn't you be better looking at the i= tag in the DKIM-Signature
header, anyway?
Since it's optional, I hadn't thought to rely on it.
Since it's intent is different, I'd be concerned about *requiring* i= as the
sole means for resolving this.
That said, if the i= is present AND it matches the rfc2821.MailFrom, then it
does indeed seem like it closes the hole that you observed.
So the Bounce SSP record would only be needed if the domains matched and there
were no i=.
The implied question that John L. raises -- squelch at source vs. squelch at
destination -- is entirely valid. I think it boils down to: Is it worth the
administrative, operational and computational overhead of this extra mechanism
to prevent generation of specious bounces?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
