Hello Azur,
On 9/20/2013 12:45 PM, DTNX Postmaster wrote:
> Has it occurred to you that the reason lots of your users enable
> forwarding to Gmail may be the fact that you accept everything? And
> that they are essentially using Gmail as the spam filter they need
> because of this?
Joni makes a very salient point here, and others made the same point as
well. I can understand your false positive philosophy, but I don't
agree with it, and neither does any other respectable mail OP today.
This philosophy may have worked in the mid 1990s when spam volumes were
low and merely an annoyance. But the situation "on the ground" of the
battlefield in 2013 makes this untenable. The spam volume has increased
over 1000 fold and is actively wrecking infrastructures when left unchecked.
Thus, taking your currently flawed philosophy into account, *at bare
minimum* you need to stop accepting spam from malware infected PCs into
your queue. You can safely reject nearly all of this bot spam at smtp
connect using Postscreen and similar methods. These look at the client
sending the spam, not the content. Thus the FP rate is zero--nobody
requests email from a spam bot. Nobody gives explicit opt-in permission
for a bot network operator to send them email. Remember, spam is
defined by consent, not content. Spambots are never given consent.
Block them.
Rejecting bots at connect should eliminate 80-90% of your inbound spam
volume. Other than putting a huge dent in the forwarding problem, this
will also:
1. Decrease network bandwidth consumed after connect
2. Decrease network bandwidth consumed during forwarding
3. Decrease disk space consumed by all the spam you're currently
accepting
4. Cut down dramatically on CPU cycles currently burned analyzing
all emails for spam
5. Generally reduce the physical hardware infrastructure required
to support your user load
6. Dramatically increase the number of email users you can support
with your current hardware infrastructure
As you can see, there are many critical advantages to rejecting the "low
hanging fruit" bot spam sources, without causing false positives.
Frankly, if I was your employer I'd have fired you already for not
having implemented measures to block bot spam, simply because of the
financial burden it places on me due to the extra infrastructure
required to ingest, forward, store it, etc. Others here likely share
this sentiment. Ingesting all bot spam, all spam, will eventually
bankrupt you. You cannot be profitable running a commercial email
operation if you're ingesting all the spam. Either the infrastructure
costs will eat all your profits, or, more likely, you will eventually
lose your customers.
On 9/20/2013 12:45 PM, Kris Deugau wrote:
> To more directly answer your original question, it would help if you
> posted an overview of your mail flow. It sounds like your forwarding
> is done via alias rather than .forward or some similar processing on
> final local delivery; choosing a different place for your forwarding
> may help cut the volume of forwarded spam.
A commercial email service should never configure per user forwarding at
the MTA level. This is why Sieve, procmail, etc exist, to allow users
to configure this themselves at the MDA level. Here, any forwarded
email is resubmitted to the MTA. As someone else pointed out, you have
an easier trail to follow if there is a problem with a specific user and
forwarding.
It also allows you, the administrator, to implement site wide MDA
delivery rules that override individual user rules. In this case, you'd
create an MDA rule that delivers any message with an appropriate SPAM
tag in the header to a user's local SPAM folder. If the user creates a
forward rule it will not forward the spam.
Yes, you have work ahead of you to rearchitect this correctly. But this
is how it should have been done in the first place. If you need
additional assistance, the first thing you need to do is tell us which
MDA you're using. Procmail, Maildrop, Dovecot LDA, etc.
--
Stan
