kyle-qmail at memoryhole
Apr 23, 2008, 12:04 PM
Post #3 of 15
(558 views)
Permalink
|
|
Re: Thousands of Bounces From Forged From Field
[In reply to]
|
|
On Wednesday, April 23 at 02:32 PM, quoth Alex Kirk:
> I run a server that's currently on the unlucky receiving end of several
> thousand bounce messages per day due to some spammer or group thereof
> forging valid addresses at my domain into the From: field of their spam.
> While it's not causing my server any real problems (unmetered bandwidth +
> plenty of available system resources is a good combination), it's
> annoying as all get-out, especially for some of my poor users who are
> receiving these bounces (and don't have the patience gained from ~8 years
> of running a public mail server to help them weather the storm).
That sounds awfully familiar! I feel your pain. :)
> Given that I'd like to actually receive any legitimate bounce
> messages sent to these addresses, I realize that the likelihood of
> there being a good solution for filtering out all of this garbage is
> pretty low. However, I figure it's worth asking here, just in case
> someone has gotten irritated enough with a situation like this to
> come up with a tool I could use to fight this mess. Even any
> pointers on header fields I could use in combination with mail
> filtering software would be great.
Well, it all depends on what you decide to call "good".
For example, coming up with a simple BATV system is relatively easy,
but can confuse some users. Here's the idea: since qmail separates all
deliveries into separate attempts, it's pretty straightforward to
create a qmail-remote wrapper that will modify the envelope sender on
a per-recipient basis. You can then create envelope sender addresses
that map to the real envelope sender in some way. A trivial example
would be, if user[at]yourdomain is sending to recip[at]otherdomain,
transform the return address into user-otherdomain[at]yourdomain (or
better yet, user-`hash(otherdomain)`@yourdomain). Then all you do is
create a qmail-queue wrapper so that email addressed to those BATV
addresses gets its recipient rewritten back to the "real" address
(user[at]yourdomain)---and you can simply reject all messages without
senders that are addressed to user[at]yourdomain, because any *real*
bounce would be addressed to user-otherdomain[at]yourdomain. This is easy
for spammers to game, if they ever realize what you're up to (which,
depending on how idiosyncratic your system is, may be particularly
unlikely), so you can add an additional quirk: use random numbers.
Thus, outbound sender addresses become user-RANDOM[at]yourdomain; the
only trick is that you have to do something like insert that randomly
generated tag into a database so that you can verify it whenever you
receive a bounce to it. And then, of course, you've got all the
problems of database management (performance, maintenance,
tag-expiration, etc.) -- all of which are very solvable, just a bit of
a pain. The upside of this kind of system is that it virtually
eliminates faked bounces. The downside is that it can have annoying
interactions with systems that rely on predictable envelope senders
(such as mailing lists).
If that's not "good", then the best you can do is something like
DomainKeys (or, more problematically, SPF), which should allow other
systems to validate your emails and ignore invalid ones. The only
problem with this idea? Most systems don't do it, so it doesn't really
help much with the bounce problem in real life (they're often better
at tasks like protecting your users from phishing attempts).
~Kyle
--
Look, I can surely say by now that I've got the antibodies to
communism inside me. But when I think of consumer society, with all
its tragedies, I wonder which of the two systems is better.
-- Pope John Paul II, 1979
|
