On Sat, 4 Jun 2005, John Levine wrote:
This completely misrepresents the purpose and function of BATV. I
know that we've had this exact same exchange at least once before, and
I really wish you would cut it out.
In my view the main purpose is to stop forgery and spoofing of MAILFROM
address and make sure that only legitimate bounces are sent on the
internet.
But if you can achieve that and carry some additional data as part of
MAILFROM, there is nothing substantially wrong with that either...
Its probably that last part that you disagree with me about, but
for now we can forget about this debate. I'm no longer developing
techniques related to carrying anything extra in MAILFROM, there is
just not enough place for it there.
It does that by adding a one-way hash of the bounce mailbox and domain
to the bounce address that the original sending domain can check. As
we've noted, the MTA needs no per-message state to generate or check
the hash. People say "it doesn't defend against replay." Well, duh, it
doesn't even try.
Ding, ding! IETF security personnel to the evaluation desk, fast!
There's two reasons for that. One is that replay isn't a
problem and isn't likely to be.
You don't know it.
It is exceedingly rare to see a deliberately forged bounce, and it is
hard to see a plausible scenario in which bad guys would want to forge
them
After being a victim of half a dozen joe-jobs, I disagree.
I'm saying that they will continue to do as they do now, but in more
complex way - they will run program that will look for encrypted MAILFROM
address in some public mail list (which people like you and me, who they
don't particularly like, participate in quite good numbers and post often)
and will extract MAILFROM address recorded there and use in their spam.
Their spam messages would be rejected and all come to you and me, how do
you like that? Is your system really working then?
other than as DOS attacks for which they already have lots of other
techniques.
The other is that even if it seemed desirable to do so, you can't, since
there is no way to tell how many bounces a message should legitimately
get. You can't tell whether a message is going to one person's mailbox
or to an exploder that will remail it to a thousand people.
First of all exploder with thousand of recipients is probably a mail list
and those reset MAILFROM to themselve.
I agree that you can't easily tell how many legitimate bounces could be
received, but I believe you can set the number to something low like 2 or
3 and be fine with it. Can also try to increase default number if message
is going to known "exploder' or just has multiple recipients in RCPT TO
but it would require database record for sent message even if it would
not be for every one and those with multiple recipients, it would still
be a problem for busy mail server, so it might not be scalable.
And BTW, I doubt that your use of BATV for abuse.net can be considered
good experimentation on if replay is a problem because I dont think
you're using abuse.net regularly as your MAILFROM address and you also
seem to be the only user on that domain.
My version of BATV has a timestamp which I added mostly so that if
someone scrapes old bounce addresses off web mail archives, BATV will
reject them, but I have seen so few BATV failures due to expired
timestamps that I'm not sure I would put in the timestamp if I were
doing it again.
Good. Your BATV use with timestamp is exactly what I have in mind. The
only thing else is that its good to change private key often. If I
understand SES also worked the same way when originally done, but its
designers went into wrong direction...
We have contemplated one minor extension. Once the DK signature scheme
settles down, we might do a version of BATV that uses the DK key to
create a remotely checkable version of the signature. There's still
no per-message state, and it's only signing the bounce address, but
this allows as an optimization that a remote MTA could check and decline
to generate the bounce instead of the original MTA rejecting it.
There is not enough space in localpart of MAILFROM to use anything but
384bit public key crypto (and security reviewers for MASS were quite clear
that you want 1024bit keys). So its not strong enough and given how its
already subject to replay attacks, I doubt of the value of using public
key unless local-part could be extended so that it has more then 64 bytes.
SES attempts to extend a BATV-like system to an all purpose
anti-forgery and/or message validation scheme, which fails for all of
the reasons that William mentioned and more. So we're not going to do
that. If you want to prevent "too many" deliveries, don't bother. If
you want message body signatures, use DK (or DKIIM or whatever it is
now.) If you want to defend against forgery bounces, use BATV. If
you want to do both, use both, but please don't waste your time and
ours discovering yet again that one combined scheme won't solve both
problems.
You might be amazed to discover that it actually can, though not quite
in the way you imagined. Stay tuned for next week's online paper
presentation coming to asrg and other relevant lists.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg