At 10:46 AM 9/18/2004 +0100, David Woodhouse wrote:
If you do need to assume that the reverse-path addresses are somewhat
private, I wonder if it would be reasonable to just set the envelope-
from on messages to some specific address, like
fenton12345(_at_)cisco(_dot_)com,
and just not accept bounces to, for example, the 2822 "from" address.
It doesn't allow for the prevention of the bounce in the first place,
but it's real simple to do. The only thing that would be new is the
ability to reject messages to certain addresses based on a null 2821
mail-from, indicating a bounce.
I feel like I must be missing something here -- what is it?
Possibly the fact that the BATV reverse-paths are expected to be dated?
You only accept bounces to them for a limited period of time -- I
personally use seven days.
So if one _is_ harvested, it has to be a recent one for it to matter.
Sure; I glossed over that detail. You would keep a couple of addresses that
are valid for bounces, and then rotate them (maybe every 4 days or so). I'm
guessing that this is close to what you're already doing.
So my question is: Beyond this technique, does the crypto piece add enough
additional value to be worth the trouble of key management, etc.?
There was the idea of having BATV include the signature from some other
signature scheme (DK, IIM, etc.) in order to limit the replay attack, and this
warrants further thought. My question of about the value of the crypto piece
refers just to BATV operating by itself.
-Jim