Dave Crocker wrote:
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?
An interesting side effect is that it would also suppress bounce messages
from mailing lists, even if they resigned. I'm not sure if this is a feature
or a bug.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html