On Fri, 2004-09-17 at 23:37 -0700, Jim Fenton wrote:
At 11:53 AM 9/17/2004 +0100, David Woodhouse wrote:
Also there's the possibility of replay attacks. One possible answer is
to merely declare that the likelihood of these is low and that we hence
don't care -- the signed reverse-path is rarely made public since it's
changed by mailing lists and generally omitted by mailing list archives.
There are other sources from which the signed reverse-path can be
gotten. The best example I can think of is that a Trojaned MUA would
have access to signed reverse-paths from all of the messages that the
user had received.
It has been suggested that over time, MTAs could start stripping BATV
reverse-paths back to the original address upon final delivery.
I'm dubious about that idea -- too many people use POP3 and then use the
Return-Path: header when reintroducing the mail, and there's the point
which I've often made elsewhere that anything which relies on third
parties to implement _anything_ is doomed.
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.
Your suggestion of 'fenton12345(_at_)cisco(_dot_)com' is just the start of a
progression of slightly harder-to-forge BATV-like reverse-paths. Yes, it
would instantly stop you getting a lot of backscatter. You could move
from that to 'fenton20040918', and give some protection against the
Trojaned MUA situation you spoke of by time-limiting the address.
You could then perhaps put a simple crypto hash on that to prevent
malicious forgery. And then you're fairly close to what I'm doing at the
moment. What I'm doing at the moment is _also_ extremely simple to do --
it's a bunch of lines of Exim configuration and no actual 'code'. It'd
be even simpler if I wasn't keeping a list of recipient domains for
which I could do SRS too (although actually I'm going to drop that bit).
http://david.woodhou.se/eximconf/include/routers-ses
--
dwmw2