The next step is to have a special bounce filter on the other end to
stop innocent people from receiving spam induced bounces. The filter
would recognize an incoming bounce and only pass it on to the user's
inbox if that user had recently sent an email to the source of the
You've almost reinvented BATV there. It puts a signature hash in the
bounce address in outgoing mail, and rejects bounces that don't have
the hash. I've used this for a while and it works very well. Trying
to match bounce sources is hopeless; if you write to
john(_dot_)smith(_at_)foocorp(_dot_)com you're likely to get responses from
jsmith(_at_)foocorp(_dot_)com or mailer-daemon(_at_)hostingcompany(_dot_)com,
consistency at all to the addresses.
But I don't see what this has to do with challenges, since they don't
look like bounces. They're ordinary mail, sent in bulk and (for the
majority due to forgery) unsolicited, i.e. spam.
What I've been referring to as bounces may more appropriately be called
challenges. Anyway, what I have been saying is that the challenge (which
currently looks like an ordinary email) be standardized so that they can be
universally recognized as a challenge. I am proposing a filter that could
recognize this challenge email. The challenge email would contain the email
address of the relevant email account in an easily parsable form so that the
filter can make sure that the challenge is being received by the user who had
just sent out the corresponding email.
Maybe we can agree on this:
Current anti-spam systems that issue challenges do so in a way that results in
innocent people being bombarded with spam triggered challenges.
A relatively simple one-time software upgrade to existing filters can easily
prevent a standardized challenge from erroneously reaching innocent email
users. Ergo widespread adoption of a challenge generating anti-spam system is
practical - at least in regard to the above mentioned issue.
NEW! Lycos Dating Search. The only place to search multiple dating sites at
Asrg mailing list