Rejecting outside "root" and "administrator" messages

About 90% of the spam coming into my server is addressed to either root or
administrator. I understand these two addresses are required, but I'm
tired of the spam. I would simply remove them entirely except that various
cron jobs running on my server use them.

Is there a way to reject messages addressed to either root or administrator
which do not originate inside my network?

--
Bill Gee

There are no 'X' chars in my email address.

Bill Gee wrote:
> About 90% of the spam coming into my server is addressed to either root or
> administrator. I understand these two addresses are required, but I'm
> tired of the spam. I would simply remove them entirely except that various
> cron jobs running on my server use them.
>
> Is there a way to reject messages addressed to either root or administrator
> which do not originate inside my network?

Simply adapt your smtpd_recipient_restrictions to first allow
your local networks, then reject mail to your system mailboxes.
Postfix always executes the listed restrictions in the order they
are specified.

smtpd_XXX_restrictions only apply to real SMTP deliveries,
so local mail delivery via the sendmail binary (like from cron)
isn't affected by them. Here's a short example:

smtpd_recipient_restrictions =
permit_mynetworks
check_recipient_access hash:/etc/postfix/denied_system_maiboxes
reject_unauth_destination

Then create+postmap /etc/postfix/denied_system_mailboxes:
root REJECT
administrator REJECT

-Chris

Thanks for the ideas. I have put this in and it seems to work for admin and
root accounts, but postmaster is still getting through. I changed the
crontab file so that it sends directly to me instead of to root.

Here are excerpts from my config files:

===== main.cf ========================
smtpd_recipient_restrictions = reject_invalid_hostname,
reject_non_fqdn_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
permit_mynetworks,
check_recipient_access hash:/etc/postfix/denied-system-mailboxes,
reject_unauth_destination,
permit

===== denied-system-mailboxes =======
root REJECT
admin REJECT
postmaster REJECT
root@example.net REJECT
postmaster@example.net REJECT

==== aliases ===========
# Everything in aliases is REM'd except these three lines
MAILER-DAEMON: postmaster
admin: root
root: myaddress

Thanks for any suggestions!

Bill Gee



Christian Winter wrote:

> Bill Gee wrote:
>> About 90% of the spam coming into my server is addressed to either root
>> or
>> administrator. I understand these two addresses are required, but I'm
>> tired of the spam. I would simply remove them entirely except that
>> various cron jobs running on my server use them.
>>
>> Is there a way to reject messages addressed to either root or
>> administrator which do not originate inside my network?
>
> Simply adapt your smtpd_recipient_restrictions to first allow
> your local networks, then reject mail to your system mailboxes.
> Postfix always executes the listed restrictions in the order they
> are specified.
>
> smtpd_XXX_restrictions only apply to real SMTP deliveries,
> so local mail delivery via the sendmail binary (like from cron)
> isn't affected by them. Here's a short example:
>
> smtpd_recipient_restrictions =
> permit_mynetworks
> check_recipient_access hash:/etc/postfix/denied_system_maiboxes
> reject_unauth_destination
>
> Then create+postmap /etc/postfix/denied_system_mailboxes:
> root REJECT
> administrator REJECT
>
> -Chris

--
Bill Gee

There are no 'X' chars in my email address.

In article <3R4sj.8081$0o7.6193@newssvr13.news.prodigy.net> , Bill Gee wrote:
> Thanks for the ideas. I have put this in and it seems to work for admin and
> root accounts, but postmaster is still getting through.

postmaster is special. The smtpd table checks don't
affect it. I believe this is the code for that.
In postfix-2.4.1, src/smtpd/smtpd_check.c lines 4114-4119 or so.


/*
* XXX 2821: Section 3.6 requires that "postmaster" be accepted even when
* specified without a fully qualified domain name.
*/
if (strcasecmp(recipient, "postmaster") == 0)
return (0);


If you want to block messages to postmaster using table lookups
under smtpd_recipient or _data _restrictions, you'll have to
comment that test out and recompile.

This feature is documented by the statement that Postfix
complies with RFC2821.

But remember client/recipient/data have
to do with position in the SMTP dialog, not with categories
of spam tests.

smtpd_client_restrictions doesn't treat postmaster specially,
because the recipient isn't yet known at that point in the dialog.

I have two sets of sender restrictions. The worst spam sources
are listed in tables under smtpd_client_restrictions.
Those are the networks so corrupt that I don't care if
I block postmaster messages from them.

(Actually I have three sets. I've got about 300 CIDRs in
Linux netfilter that aren't allowed to reach Postfix at all.
You can do this with little performance hit if you keep
them in their own table. Jump from INPUT to that table
when you see a SYN packet to port 25. But I digress.)

The rest of the known sources are listed in tables
under smtpd_recipient or _data. I get spam to postmaster
from them.




Cameron

Bill Gee wrote:
> About 90% of the spam coming into my server is addressed to either root or
> administrator. I understand these two addresses are required, but I'm
> tired of the spam. I would simply remove them entirely except that various
> cron jobs running on my server use them.
>
> Is there a way to reject messages addressed to either root or administrator
> which do not originate inside my network?
>
Others have told you about rejecting mail to system addresses, but don't
forget that you can also redirect them to your normal mailbox by adding
a line or two to /etc/aliases and rebuilding the alias database with
newaliases.

If you're using Spamassassin there's an additional option. You can
define local rules to mark mail to root or administrator from outside
your domain as spam.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

Thanks, Cameron. I suspected "postmaster" was a special case.

I have chosen to handle it outside of Postfix. I *never* receive legitimate
email to that address, so I set up an inbox rule that automatically deletes
anything addressed to postmaster. The volume of messages is not high
enough to affect performance of my mail server.

I, too, have set up a large number of addresses in the access.db table. I
knock out all of the Latin America and most of the Asia/Pacific addresses
at their Class A number. I have no email correspondants in those regions
of the world. The postfix logs show roughly 30 to 50 messages per day
blocked from those addresses. It shows in the range of 200 messages per
day blocked from servers with invalid names, invalid MX records or no DNS
entry.

Bill Gee



Cameron L. Spitzer wrote:

> In article <3R4sj.8081$0o7.6193@newssvr13.news.prodigy.net> , Bill Gee
> wrote:
>> Thanks for the ideas. I have put this in and it seems to work for admin
>> and root accounts, but postmaster is still getting through.
>
> postmaster is special. The smtpd table checks don't
> affect it. I believe this is the code for that.
> In postfix-2.4.1, src/smtpd/smtpd_check.c lines 4114-4119 or so.
>
>
> /*
> * XXX 2821: Section 3.6 requires that "postmaster" be accepted even
> when * specified without a fully qualified domain name.
> */
> if (strcasecmp(recipient, "postmaster") == 0)
> return (0);
>
>
> If you want to block messages to postmaster using table lookups
> under smtpd_recipient or _data _restrictions, you'll have to
> comment that test out and recompile.
>
> This feature is documented by the statement that Postfix
> complies with RFC2821.
>
> But remember client/recipient/data have
> to do with position in the SMTP dialog, not with categories
> of spam tests.
>
> smtpd_client_restrictions doesn't treat postmaster specially,
> because the recipient isn't yet known at that point in the dialog.
>
> I have two sets of sender restrictions. The worst spam sources
> are listed in tables under smtpd_client_restrictions.
> Those are the networks so corrupt that I don't care if
> I block postmaster messages from them.
>
> (Actually I have three sets. I've got about 300 CIDRs in
> Linux netfilter that aren't allowed to reach Postfix at all.
> You can do this with little performance hit if you keep
> them in their own table. Jump from INPUT to that table
> when you see a SYN packet to port 25. But I digress.)
>
> The rest of the known sources are listed in tables
> under smtpd_recipient or _data. I get spam to postmaster
> from them.
>
>
>
>
> Cameron

--
Bill Gee

There are no 'X' chars in my email address.

In article <ruYtj.6515$xq2.272@newssvr21.news.prodigy.net>, Bill Gee wrote:
> Thanks, Cameron. I suspected "postmaster" was a special case.
>
> I have chosen to handle it outside of Postfix. I *never* receive legitimate
> email to that address, so I set up an inbox rule that automatically deletes
> anything addressed to postmaster. The volume of messages is not high
> enough to affect performance of my mail server.

You'll get away with that on a personal or hobby server.
But it's dangerous, because high quality spam reports probably
won't be addressed anywhere but postmaster@ and abuse@. RFC2142.
People who go to the trouble of reporting spam won't do the
extra work of figuring out some unusual way to contact you.
So if you have a weak SMTP AUTH password stolen/guessed,
or $Diety forbid you get rooted, you're blocking one of
the main ways you'd find out you're sending abuse.



> I, too, have set up a large number of addresses in the access.db table. I
> knock out all of the Latin America and most of the Asia/Pacific addresses
> at their Class A number. I have no email correspondants in those regions
> of the world. The postfix logs show roughly 30 to 50 messages per day
> blocked from those addresses. It shows in the range of 200 messages per
> day blocked from servers with invalid names, invalid MX records or no DNS
> entry.

I've got a few /8s blocked, but most of them have too many
non-abusive holes. My users get legitimate email from Australia,
Japan, and Argentina, unfortunately. It wouldn't bother
us if Russia and Turkey were entirely disconnected from
the Internet.

200 bad DNS contacts per day? I'm getting that many per minute.
and that's not counting what bounces off the netfilter.
Which reminds me to ask about selective logging in a new thread.


Cameron

In article <slrnfs4ehm.lgs.spambait@truffula.sj.ca.us>,
spambait@merde.greens.org says...
> I've got a few /8s blocked, but most of them have too many
> non-abusive holes. My users get legitimate email from Australia,
> Japan, and Argentina, unfortunately. It wouldn't bother
> us if Russia and Turkey were entirely disconnected from
> the Internet.

Excuse the idle curiosity... but how can you be sure of this sort of
thing? Just because you don't notice any legal mail from said countries
is no guarantee of no possible _future_ legal mail from there.

I gather from the stats you mentioned that you have rather a lot of
users, with varied international contacts. At any given time any of them
might want to converse with someone in Russia or Turkey without telling
you, first... I'm saying this, looking at a server that would benefit a
lot from blackholing, frex, Brazil wholesale, but there are about 2000
users whom I'd rather not re-ask every day whether or not they are
interested in talking to anyone in Brazil today.

rgds,
netcat

In article <MPG.222e57d3ca79fdd498983b@news.octanews.com>, netcat wrote:
> In article <slrnfs4ehm.lgs.spambait@truffula.sj.ca.us>,
> spambait@merde.greens.org says...
>> I've got a few /8s blocked, but most of them have too many
>> non-abusive holes. My users get legitimate email from Australia,
>> Japan, and Argentina, unfortunately. It wouldn't bother
>> us if Russia and Turkey were entirely disconnected from
>> the Internet.
>
> Excuse the idle curiosity... but how can you be sure of this sort of
> thing?

I can't. But my 550 notice has a URL for an un-block request form.
Someone fills it out perhaps once a month.
It's usually a hobby server on residential DSL or cable
with generic rDNS.



> Just because you don't notice any legal mail from said countries
> is no guarantee of no possible _future_ legal mail from there.

I'm not looking for a guarantee. Just a reasonable expectation.
Certain countries are widely blocked. They seem to me to have a
different email culture that isn't compatible with ours. I expect
mine will not be the first .US server that ever blocked their
..TT or .RU client. (Or .KR or .BG ...)
People in those nations learn pretty fast to use something like
Yahoo Mail for a secondary account, if they're using their
domestic email provider's outbound SMTP at all.


>
> I gather from the stats you mentioned that you have rather a lot of
> users, with varied international contacts. At any given time any of them
> might want to converse with someone in Russia or Turkey without telling
> you, first... I'm saying this, looking at a server that would benefit a
> lot from blackholing, frex, Brazil wholesale, but there are about 2000
> users whom I'd rather not re-ask every day whether or not they are
> interested in talking to anyone in Brazil today.

If this were a business, I wouldn't get away with such aggressive
blocking. But I'd also have a budget for several modern CPU cores'
worth of Spamassassin bandwidth, and another core for a policy
server to do some fancy greylisting and reputation tracking.

Most of these incoming spam attempts are part of something that
looks like an enormous dictionary attack. It's been going on
for a year on one domain and it started a few months ago on
a couple of others. The localparts are a concatenation of
a couple of random common names and a dictionary word.
They come from everywhere, but when one hits it hits over and
over on and off for several hours. Then I never see that IPA again.
I'd love to be able to, e.g., block those in the netfilter for a few
hours after they've tried e.g. eight bad addresses and no good ones
within a minute or two. But that gets to be a database app that
I don't want on the same host as Postfix.


Cameron

In article <slrnfs9dae.s16.spambait@truffula.sj.ca.us>,
spambait@merde.greens.org says...
> In article <MPG.222e57d3ca79fdd498983b@news.octanews.com>, netcat wrote:
> > In article <slrnfs4ehm.lgs.spambait@truffula.sj.ca.us>,
> > spambait@merde.greens.org says...
> >> I've got a few /8s blocked, but most of them have too many
> >> non-abusive holes. My users get legitimate email from Australia,
> >> Japan, and Argentina, unfortunately. It wouldn't bother
> >> us if Russia and Turkey were entirely disconnected from
> >> the Internet.
> >
> > Excuse the idle curiosity... but how can you be sure of this sort of
> > thing?

> I'm not looking for a guarantee. Just a reasonable expectation.

That is of course all well and fine just as long you are sure that your
clients share the same expectations with you.

> Certain countries are widely blocked. They seem to me to have a
> different email culture that isn't compatible with ours.

Our servers are hit by tens of thousands of zombied U.S. dsl clients
every day, shouldn't you conclude you have an e-mail culture
incompatible with the rest of the civilized world as well? ;-)

It _used_ to be most spam came from countries that did totally ignore
foreign abuse notices. And I mean mostly Asia, by that.

However, nowadays the most spam comes from wherever the largest ignorant
masses of home broadband users are.

> People in those nations learn pretty fast to use something like
> Yahoo Mail for a secondary account, if they're using their
> domestic email provider's outbound SMTP at all.

I sincerely doubt that companies, research institutions and such in any
large country would be using Yahoo Mail accounts or overseas hosting.

> If this were a business, I wouldn't get away with such aggressive
> blocking.

Indeed as I suspected.

> But I'd also have a budget for several modern CPU cores'
> worth of Spamassassin bandwidth, and another core for a policy
> server to do some fancy greylisting and reputation tracking.

Yeah. I'm not complaining about spam getting through, merely envying the
expedience of wholesale blocking, it being so much more resource
efficient.

rgds,
netcat