-   Linux - Server (
-   -   Postfix setup to block spam from/to my own address (

SciFi-Bob 06-21-2011 02:52 PM

Postfix setup to block spam from/to my own address
Hi, I have set up a couple of postfix servers for my domains, but the only thing I am missing now is this:

How to block the public sending mail from my email to my email?

I have managed it with SPF, but surely there must be a better way, that returns "relay not allowed" to the client.

The SPF method costs too much, since it must make a dns request for each mail.

So far, I have not gotten many of these mails, unless when testing my mailserver, but as I see it, anyone should not be allowed to send mail from to

Somebody must have thought about this a long time ago, and there is simply that little line in main.conf that I'm missing..

My setup is this (virtual):

I have a primary mx, with postfix, courier IMAP/POP3 server, a user database, and sasl via saslauthd.

I also have a secondary mail server (backup mx) with no sasl auth, but with a copy of the mail users in the virtual tables, but added as relay_* users instead.

Spamassassin and SPF testing is replicated too, so most of the stuff should work, but I simply cannot find a setting in Postfix that denies someone to mail FROM my address TO my address.

When mailing from my address and out in the open, they are required to authenticate, but not when using one of my my domain addresses, and also targeting my domain addresses.

As said, It is possible with a strict SPF setting, but that is at a cost for every lookup. It would be quicker for postfix to lookup the sender and the recipient in the relay/virtual tables, and deny if both addresses were in the recipient tables, and sender is not authenticated.

Puh.. Thats my problem, any solution?

Noway2 06-21-2011 07:37 PM

off hand, something doesn't sound quite right with this. I would think that your Postfix should recognize that they are not authorized. Unless of course, it is just looking at the recipient and saying "thats for local delivery" and the sender address is immaterial... Interesting.

What do you have for your smtpd_recipient_restrictions?
For comparison, here is what I have:

  check_policy_service inet:

You might also want to look at HELO restrictions of some form which will stop a lot of spam.

SciFi-Bob 06-22-2011 12:19 AM

This is mine:


smtpd_recipient_restrictions = reject_unauth_pipelining,
        check_policy_service unix:private/policyd-spf,

and here are my sender restrictions:


smtpd_sender_restrictions = permit_sasl_authenticated,

Edit: I solved it in a way, by modifying "~all" to "-all" in all my SPF records in dns. So at least no unauthenticated hosts are allowed to send mail from any of my domains unless they are listed in my SPF.

Noway2 06-22-2011 05:19 AM

The more I think about your situation, the more I think you are right that there must be a way to detect this. At the same time, I think if you look at your logs carefully you will see that the messages are being accepted on the basis that you are the recipient or recipient domain. Therefore, the "trick", if you will, is to detect that they are using bogus information.

With that in mind, please take a look at this archive thread from google groups where it looks like someone was having a very similar problem. Towards the bottom are a couple of things that may work.

1) reject_sender_login_mismatch - this will require that the sender, when claiming to be you will need to be logged in via SASL authentication. Clearly they are not.
2) setup to reject on your domain as the sender, put place this AFTER permit my networks and SASL authenticated. This means that if the sender is "you", but you haven't authenticated or are from behind the scenes on your own server then clearly you are not you.
3) if you haven't already, scour the restrictions lists and try various things.

A couple of other thoughts: One, I would recommend, just to be safe, to use a tool like and double check that you aren't inadvertently an open relay. The sender spoof looks a little close to that and the 5 minutes of effort is worth the peace of mind. Two, my personal experience has been that I needed to put reject_rbl_client towards the top. Check your logs to see if you are blocking any spam on this function (it will says blocked and if not, change the order. This too is a DNS lookup, but it is better than content filtering or letting it get into your queue.

SciFi-Bob 06-23-2011 08:28 PM

I will check the reject_sender_login_mismatch option, and see if it does any difference.
Logically, in my view, that option would only block authenticated senders trying to send as somebody else, but maybe it goes a bit further.

Anyway, in the first case, a nice thing to have, unless it blocks legal external senders to my domain.
Would not want any authenticated clients on my net to post messages as root unless I authorized them.

Otherwise, I have checked the log, and I am stopping spam mails, both on the spf check (quite a lot), by spamassassin and the policy (also quite a lot).

The sequence should not matter (excluding dns and spamassassin overhead, but optimizing is next, first is blocking..), unless the check_policy grants "permit" in some cases. I would not expect that, but if that is true, it may be the culprit.
I must admit I don't know the exact result of the spf plugin policy.

The policy check is defined like this in

policyd-spf unix - n n - 0 spawn
user=policyd-spf argv=/usr/bin/policyd-spf

Edit: To add this: There is no way my server is an open relay. Any attempt to mail to any domain (and any non-existing user in any of the domains) not listed in virtual domains failed, unless authenticated.

But I want to block anonymous users posting to me from me. That is the culprit..
I will modify the configuration, and run some tests in the weekend, to see if I can stop this.

SciFi-Bob 07-23-2011 06:20 PM

I finally solved this by using smtpd_sender_login_maps.

It limits the sender address any authenticated user can use, so it's a perfect solution to my problem.

You just have to maintain a list of what addresses every user is allowed to use. In my case it's easy, because I use LDAP, and I just have to do a lookup in the alias table for every user. The data is already there.

All times are GMT -5. The time now is 01:37 PM.