Jim Lyon wrote:
2. bounce address tells you who wants to know if the message isn't
delivered. It's also irrelevant when deciding whether the MTA is
authorized to act of behalf of the name mentioned in the message he's
The (2821 MAIL FROM) bounce address is irrelevant? This seems absurd
considering how many bounces (containing spam and viruses) I get for
messages I never sent. They are a *means* (not just a result) of delivering
messages, and exploited widely. Several viruses and spammers intentionally
use the method of bouncing to get their messages around filters and
And (even worse), the volume and content of bounce-related messages I
currently receive overwhelm my ability to detect when an honest bounce
occurs. Just a couple days ago, I found that a certain ISP has been
incorrectly blacklisting one of my MTA's IP addresses for weeks, but it
wasn't noticed because the DSNs were buried with all the spam/virus DSNs.
It appears that the bounce address attack scenarios against SenderID that I
and others (Shevek and Mark Shewmaker to name a few) brought to the
attention of this list have been ignored. Instead of modifying SenderID to
solve these problems, the problem is now "irrelevant". How convenient.
The MAIL FROM bounce address IS relevant. SenderID doesn't protect the
bounce address adequately, and it amazes me that people are arguing over the
IPR of a technology that is so obviously flawed in this respect.
Preventing forgery involves several levels:
First, protect the transfer agents:
turn off open relaying, use AUTH, maybe CSV
Second, protect the envelope:
via technologies like SPF or RMX
Finally, protect the message and header:
via crypto signing like SMIME or DomainKeys
The first levels are the least expensive to perform but provide the least
protection. The last levels are the most expensive, and work best if the
earlier levels are already implemented.
Because SenderID tries to cheat the last two steps, it uses envelope checks
on the message header and appears to protect neither.
Michael R. Brumm