On Mon, 2004-12-06 at 10:01 -0800, Michael Thomas wrote:
First, MAIL FROM: does have the ambiguity of what you
do for <> in a bounce message. Surely you'd like to
be able to auth/authz bounces?
Not in the same way, no. Authentication of _bounces_ is something
entirely different. You don't want to know if the message really did
come from the party from whom it claims to come -- you want to know if
the message is a bounce to a mail _you_ actually _did_ send and not a
bounce to a faked mail. That's something completely orthogonal, which is
addressed by separate solutions. For that you want SES.
I stopped getting bounces to mail I didn't send in February of this
year; I don't need MASS to solve that particular problem for me and I
don't think it's within the scope of MASS to attempt to deal with it.
But that said, Jim has been toying with the idea that the
_signer_ just includes in the signature the address(es?)
that it wants to take responsibility for. If I understand
him correctly, it is not necessarily correlated with any
particular 2822 header tag (eg, from, sender...). Again if I
understand this correctly, it would be up to the receiver to
determine which address that it cares about and find a
corresponding signature that contains that asserted address.
Unless you can actually use it to _reject_ mail, it's fairly much
pointless for the most part. So handwaving like that can only be a cover
for the fact that it can't actually be useful.
Thus, it seems plausible that a MASS signer could have it
either way? I personally have been pretty reluctant to pick
one kind of 2822|2821 address as being The address that MASS
gives auth/authz; it seems prudent to me to be flexible so
that if the problem mutates, so can we.
I'm up for authenticating RFC2822 addresses in a way which survives the
common mangling it'll get. Or I'm up for using RFC2821 addresses. Either
of those makes sense. But authenticating only the 'most recent' RFC2822
address is just silly.
--
dwmw2