qmail, spams and mailer-daemon
Heidi Grab
I have app. 4000-5000 incoming spam e-mails daily. 83 percent of it is
recognized as spam by spamassassin and 0 percent of ham. (If we get
tighter on spamassassin, there is ham also getting caught, so we
decided to leave it as it is for now.)
Over 60 users have set up their e-mail accounts so that they get their
e-mails forwarded.
Until recently we did not interfere with their e-mails. We marked them
as probable spam, but continued to deliver them.
However, since the number of spam mails is constantly on the rise, we
decided to block spam messages with a 5.7.0 error message (Your e-mail
is probable spam. Please write to .... if we are wrong.)
Well, as you can imagine, this did not decrease the load on the mail
server. The mails do not get delivered to their original recipients,
but the 5.7.0 mailer-daemon message tries to get through - and almost
always in vain, because either the return adress is a fake and doesn't
exist or the e-mail adress is a fake and the recipient doesn't even
know that some spam bot used his e-mail adress to fake messages.
Any way, those 5.7.0 messages seem to be completely useless, because
they never reach the sender anyway.
What do you think about delivering spam messages to /dev/null? And how
could we adjust the dotqmail files to do this?
I know, there are downsides to this. I'm just so mad at all this
spammers, I want to do something. I'd be happy to discuss the matter
(and, of course, better ideas) with you.
Yours,
Heidi.
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Oliver Welter
Hash: SHA1
Hi Heidi,
> However, since the number of spam mails is constantly on the rise, we
> decided to block spam messages with a 5.7.0 error message (Your e-mail
> is probable spam. Please write to .... if we are wrong.)
>
> Well, as you can imagine, this did not decrease the load on the mail
> server. The mails do not get delivered to their original recipients, but
> the 5.7.0 mailer-daemon message tries to get through - and almost always
> in vain, because either the return adress is a fake and doesn't exist or
> the e-mail adress is a fake and the recipient doesn't even know that
> some spam bot used his e-mail adress to fake messages.
>
> Any way, those 5.7.0 messages seem to be completely useless, because
> they never reach the sender anyway.
>
> What do you think about delivering spam messages to /dev/null? And how
> could we adjust the dotqmail files to do this?
NO Dont do this! Its against RFCs and will make your users angry if you
drop legal messages silently.
The better approach is, to reject the Spams at SMTP Level. This is
independant of any forged Envelopes and leaves the creation of a "Non
Delivery Report" to the contacting MTA. In most cases this will be a
spammer who is not interessted in NDRs, but thats not your business.
A second option might be greylisintg - I know there is an ongoing
disussion about the usage of greylisting but at least for me, it figures
out to work. My SMTP Server gets around 10.000 SMTP connects per hour,
after greylisting, only around 500 survive which is than handled without
hassle by our servers.
I use the qmail-spp patch together with
http://manuel.mausz.at/coding/qmail-spp/greylisting/ and qmail-scanner
with the "st patch" http://toribio.apollinare.org/qmail-scanner/
Oliver
- --
Protect your environment - close windows and adopt a penguin!
PGP-Key: 3B2C 8095 A7DF 8BB5 2CFF 8168 CAB7 B0DD 3985 1721
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJDXb9yrew3TmFFyERApsaAJ9vXxMyoEGO2EK8vKE8e1idyYRdNwCeMQq2
DaFbFo0V4xA9oV9WoLHWXLw=
=cdRU
-----END PGP SIGNATURE-----
John Simpson
Hash: SHA1
On 2008-11-02, at 0325, Heidi Grab wrote:
>
> What do you think about delivering spam messages to /dev/null? And
> how could we adjust the dotqmail files to do this?
first, make sure that you KNOW the messages are spam. if you're not
100% sure, it's safer (in terms of not losing legitimate messages) to
just pass it through to the intended recipient, and let them deal with
the effort of hitting the DELETE key.
and even if you are 100% sure- if the sending IP is a known spammer,
for example- then your best bet is to simply refuse to accept the
message during the SMTP transaction. that way if it IS a legitimate
message, the machine which tried to hand it to you will try again, or
it will generate a bounce message. and if the sender is a spammer,
they will not have succeeded in making your machine deal with the
message to begin with.
if you really feel the need to accept the message and then drop it,
create the appropriate ".qmail" file with "#" as the only line. qmail-
local will see that the .qmail file exists, and isn't empty, so it
will use it. and if the file contains no real delivery instructions,
the message won't ever really be delivered anywhere, but qmail-local
will tell qmail-send that the message was successfully delivered, and
qmail-send will remove it from the queue like it would any
successfully delivered message.
another problem with this approach is that the spammer will only know
that your server accepted the message, so they will continue to send
messages to your server. it's one less message stuck in THEIR queue,
so you're actually making things a little bit easier for them.
> I know, there are downsides to this. I'm just so mad at all this
> spammers, I want to do something. I'd be happy to discuss the matter
> (and, of course, better ideas) with you.
been there, done that, and i've had this same discussion with the same
list in the past. and if i'm not mistaken, the same "oliver" guy who
already answered you, also tried to berate me for "violating the RFCs"
by dropping the messages, even though i was 100% sure that they were
spam. i had written a patch for qmail-smtpd which gave it a way to
send "250 ok Your SPAM has been ignored." to the client, without
actually handing the message to qmail-queue.
my response is the same as it was then- the RFCs are just a set of
recommendations, and have no legal "force of law" or anything like
that. WHO CARES if he agrees with my methods or not? if i KNOW that a
particular message is spam, and the message is physically present on
MY hardware, then nobody can tell me that i can't delete it.
in fact, the RFC is actually being complied with, because the message
IS being delivered to where my machine's owner feels it needs to be-
straight into the trash. deleting the message on the way INTO the
queue, as opposed to deleting it on its way OUT OF the queue, is just
a case of saving time.
whatever you decide, the final decision is yours. just make sure it's
an intelligently thought-out decision, rather than a knee-jerk
reaction because you're angry at the spammers.
- --------------------------------------------------------
| John M. Simpson -- KG4ZOW -- Programmer At Large |
| http://www.jms1.net/ <jm...@jms1.net> |
- --------------------------------------------------------
| Hope for America -- http://www.ronpaul2008.com/ |
- --------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkkODOwACgkQj42MmpAUrRr3YgCeIs1PKhRId5qqJlIghEjwmlCN
VTYAn2fugWahwczG8ymqEBKhb8vni/zM
=djCl
-----END PGP SIGNATURE-----
Kyle Wheeler
Hash: SHA1
On Sunday, November 2 at 09:25 AM, quoth Heidi Grab:
> I have app. 4000-5000 incoming spam e-mails daily.
That's it? ;)
> 83 percent of it is recognized as spam by spamassassin and 0 percent
> of ham. (If we get tighter on spamassassin, there is ham also
> getting caught, so we decided to leave it as it is for now.)
That's pretty good, but 0 false positives is, at best, not perfectly
sustainable. Spamassassin makes no guarantees, and so you shouldn't
rely on it to give you guarantees, no matter how you have it
configured. It's like the stock market: past returns are no guarantee
of future performance.
> Over 60 users have set up their e-mail accounts so that they get
> their e-mails forwarded.
>
> Until recently we did not interfere with their e-mails. We marked them as
> probable spam, but continued to deliver them.
Which, given that that's exactly what they told you to do, would make
sense.
> However, since the number of spam mails is constantly on the rise,
> we decided to block spam messages with a 5.7.0 error message (Your
> e-mail is probable spam. Please write to .... if we are wrong.)
PLEASE do not do that. The return address is almost *ALWAYS* fake, and
you're just allowing the spammer to use your system as part of a
denial-of-service attack on whoever owns the fake return address.
> Any way, those 5.7.0 messages seem to be completely useless, because
> they never reach the sender anyway.
More than useless, they're *annoying* and they will eventually get
YOUR system added to blacklists.
> What do you think about delivering spam messages to /dev/null?
There's nothing technically wrong with it (as long as you're speaking
metaphorically - there's a better way to delete a message than to send
it to /dev/null), but you'd be playing with fire. Every message
deleted is a message you can never resurrect if your classifier gets
something wrong.
> And how could we adjust the dotqmail files to do this?
John explained this fully, I think.
> I know, there are downsides to this. I'm just so mad at all this
> spammers, I want to do something. I'd be happy to discuss the matter
> (and, of course, better ideas) with you.
Totally.
But you don't want the spammers to drive you to do something in a fit
of passion that you'll come to regret later. For one thing, my advice
is: whenever there is even a minute change in policy (often even if
you don't think your users can tell), you need to keep your users
informed. Some of my users, for example, find the idea of *blocking*
rather than *tagging* email utterly abhorrent because they've been
bitten by false-positives before. So in my system, I needed to
maintain a method of altering spam-blocking preferences on a
per-recipient basis (thankfully, this hasn't yet become too much of a
problem). In any case: communication with your users is crucial.
Explain what you're doing (i.e. that you won't be forwarding spam
anymore), what the visible repercussions are (i.e. miscatecorized
email will be completely un-salvageable) and why (i.e. you're running
out of bandwidth).
Another thing to consider is this: the earlier in the SMTP process you
can reject a message, the better. You don't have to *accept* the
message into your queue, you can simply reject it there. Then you
don't have to delete it, and the sending server gets to worry about
whether to notify the sender. This kind of behavior is safe: it
doesn't turn your server into a spam reflector, and honest (non-spam)
senders still get bounces (just not from you).
Personally, I use spamassassin to break email into three categories,
based on their score ranges: definitely spam (8+ points---deleted),
definitely ham (< 3 points---delivered), and "uncertain" (3-7
points---sanitized and delivered, often to a special folder). I let my
users fiddle with the boundaries of those ranges, though they usually
stick with the defaults, and it largely avoids much mess.
I guess, I'm just advocating that you be very cautious when deleting
messages. Just one unrecoverable mistake can make a lot of users very
mad. When you're up-front with them, and give them control over what
gets deleted and what doesn't, that (in my experience) avoids a lot of
problems. Heck, it may be worth it to keep an archive of the last
week's worth of spam, rather than deleting it immediately. Yes, that's
a lot of disk space, but it's an insurance policy against
miscategorized mail (and your users will not only feel better knowing
it's there, but will probably report missing mail to you quickly, if
it happens).
~Kyle
- --
Only the fool hopes to repeat an experience; the wise man knows that
every experience is to be viewed as a blessing.
-- Henry Miller
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!
iEYEARECAAYFAkkPQTUACgkQBkIOoMqOI15/cACgycr2incl167ZCFbFWA7sdy9Z
cVEAni0UH5SOnDxkijTIwkGzFz2ly0qs
=GStK
-----END PGP SIGNATURE-----