On Tue, 2005-07-05 at 21:37 -0700, Greg Connor wrote:
All good ideas. I think it's a good idea to be prepared for such an
eventuality. Right now it's a theoretical answer to a theoretical
problem that might occur if we use the theoretical proposal. We need
more real-world experience in that area.
I'm not sure how attractive such an attack would even be to spammers.
Even if such signed addresses were to become common, there would be
relatively few harvestable addresses in any given victim's inbox.
The effort of finding the addresses probably outweighs the benefit,
especially given the fact that if you can hi-jack the users' MUA to that
extent, you're likely to be able to just _use_ it to send mail instead
of faking addresses. Perhaps I'm showing my ignorance here -- I'm not
sure why that particular tactic isn't more widely used anyway. Perhaps
because so many recipients don't bother with even the most _basic_
checks on the reverse-path, let alone callbacks or even SPF.
So far, my response to this theoretical problem has been to ignore it. I
can't really see it ever being a problem in _practice_. Remember, I'm
not suggesting that my bank manager should act upon instructions he
receives in email merely because it has a valid SES reverse-path. We
have GPG for that.
Making the timing stricter after an hour after generation tightens
things even further, without affecting legitimate users, but makes even
the easier look-through-mailing-list-archives-for-mailfroms trick less
useful.
You tend not to get the original reverse-path in mailing list archives.
The archival is mostly done on the recipient side of the mailing list,
where the reverse-path has generally been changed already to the list's
own bounce handling address. Also, since the Return-Path: header (where
present) is added by the delivering MTA, it may well not be present when
the archival is done within the mailing list software itself. In fact
it's even more likely to be omitted from the actual archive, along with
a whole bunch of other headers. Annoyingly, some versions of mailman
even strip References: and In-Reply-To: headers from the archive, IIRC.
I personally would guess that an aggressive timeout would work fine (like 1
hour). It's really there to get past the odd forwarding arrangement of the
receiver. Most receivers will be satisfied with the a, mx, ip or whatever
is front-most on your SPF record. Someone who is checking an hour after
the fact isn't likely to use the result to reject the mail.
I wouldn't advocate reducing the timeouts. Although email _should_ be
passing to its final recipient within a few seconds in the common case,
you really need to deal with outages of up to a few days. To do
otherwise will destroy the reliability of the system.
I wonder if David has any data on how much later the signed address get
hits or callbacks? That would be interesting data...
Sorry, I don't have information on callbacks which happen before the
expiry period expires; they don't get logged. Given that I allow three
weeks for an address to expire, it may not amaze you to hear that I
don't have any cases of callbacks to expired addresses in my logs at the
moment.
I do have a bunch of attempts to deliver to obviously-harvested
addresses like $user(_at_)$host(_dot_)srs(_dot_)infradead(_dot_)org though,
where the
harvesting mechanism got confused by the + sign before the username. So
evidently a signed address has made its way to the web _somehow_. These
are not callbacks or bounces though; these are mail with non-empty
reverse-path.
/me googles... OK, a counterexample to the _normal_ behaviour of mailing
list archives which I described above can be seen at
http://lists.debian.org/debian-legal/2005/04/msg00182.html
--
dwmw2