On Oct 21 2004, Arnt Gulbrandsen wrote:
I guess I wasn't clear. Sorry. Let me try again.
1. Quoting the time isn't good. If I'm allowed 150 tries and can bounce
some mail off your server to read the bounce messages, I can guess when
you'll process a message.
Ah, I think I understand your point. You could use 150 bounces as tracers,
to compute an estimate of the processing time: e.g. send a test
message designed to bounce, containing the time that the SMTP transaction
was initiated, and later read back the timestamp which was added. Then
do a regression line estimate. Something like that could probably work,
although a proof of concept would be nice.
In another post, I mentioned possibly extending the RFC 2822 date-time stamp
to include microseconds. Would that be sufficient protection against such
a timing attack, or would Moore's law render this useless over time?
2. Quoting the "with" ID may provide protection, depending on whether
the ID is guessable.
Yes. From the RFC, this is optional. Do you know any good reasons why the ID
might not be added to a Received line sometimes?
3. A receiver can make its IDs less guessable. A few bytes of randomness
are easily obtained. (A receiver cannot easily make the time of day
more difficult to predict.)
One easy way is to add a small random delay in the middle of the
processing step. If for example each transaction is on a different
thread, this delay would be used to sleep while another thread
executes, so time isn't wasted.
4. Most MTA authors seem eager to implement anything that helps against spam.
I expect so. I think it's important to try to work with the existing
standards as much as possible, which is why I'm looking at ID and date
rather than say something like: MTA authors must insert a new random
string token in each Received line which they write.
Conclusion. Quoting the "with" ID is good, and the MTAs that currently
have guessable IDs will change that quickly if spammers ever exploit
it.
Thanks, those comments are helpful.
--
Laird Breyer.