11

I would like to receive system emails from my home server. So I'm trying to configure postfix to do that through my public server. My public server has a fixed IP, while my home server is in a private network with a messed up hostname due to my router's hostname being included in the hostname, leading to a full hostname "homeserver.blablabla_crappyrouter".

My home server connects to my public server through an OpenVPN tunnel with fixed IP where my home server is a client. From my home server to my public server (and vice-versa) there's a fixed IP, so they can reach each other with no problem through a fixed address. This is a tunnel that gets me to reach my home server from anywhere with no security problems.

My postfix configuration on my public server includes the following:

smtpd_recipient_restrictions = reject_invalid_hostname,
        reject_unknown_recipient_domain,
        reject_unauth_destination,
        reject_rbl_client sbl.spamhaus.org,
        permit

smtpd_helo_restrictions = reject_invalid_helo_hostname,
        reject_non_fqdn_helo_hostname,
        reject_unknown_helo_hostname

smtpd_client_restrictions = reject_rbl_client dnsbl.sorbs.net

And on my home server, I added my OpenVPN's public server's IP using

relayhost = [<public server IP through OpenVPN>]

Now this configuration doesn't send emails and gives me the error:

Helo command rejected: Host not found

I researched this, and found that postfix searches for the hostname, but apparently it doesn't find it due to its messed up hostname.

My question: How can I tell my public server's postfix to allow everything from my homeserver blindly?

Thanks.

UPDATE:

I did set the option in main.cf

smtpd_helo_required = no

but this didn't help. The following are the /var/log/mail.log entries right after I send a test e-mail:

Sep  2 15:53:53 HomeServer sm-mta[6677]: t82Drr6w006677: from=sys@mydomain.com, size=69, class=0, nrcpts=1, msgid=<201509021353.t82Drr6w006677@HomeServer.blablabla_crappyRouter>, proto=ESMTP, daemon=MTA-v4, relay=localhost [127.0.0.1]
Sep  2 15:53:53 HomeServer sm-mta[6679]: STARTTLS=client, relay=mydomain.com., field=cn_subject, status=failed to extract CN
Sep  2 15:53:53 HomeServer sm-mta[6679]: STARTTLS=client, relay=mydomain.com., field=cn_issuer, status=failed to extract CN
Sep  2 15:53:53 HomeServer sm-mta[6679]: STARTTLS=client, relay=mydomain.com., version=TLSv1/SSLv3, verify=FAIL, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256
Sep  2 15:53:53 HomeServer sm-mta[6679]: t82Drr6w006677: to=info@mydomain.com, delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=120069, relay=mydomain.com. [93.186.192.197], dsn=4.7.1, stat=Deferred: 450 4.7.1 <HomeServer.blablabla_crappyRouter>: Helo command rejected: Host not found

The mail I'm trying to send is:

ehlo localhost
mail from: sys@mydomain.com
rcpt to: info@mydomain.com
data
Subject: My first mail on Postfix

Hi,
Are you there?
regards,
Admin
.
quit

and I send it using the command:

cat mail.txt | nc localhost 25
The Quantum Physicist
  • 656
  • 2
  • 11
  • 25

3 Answers3

10

Here's the issue:

smtpd_helo_restrictions = reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    reject_unknown_helo_hostname

The last of those, reject_unknown_helo_hostname, tells Postfix to reject mail if the hostname given in the HELO command cannot be resolved. If you remove that, your problem should go away.

You should reverse the change you did (setting smtpd_helo_required to no). That change made it so that a client can connect and start sending mails without doing a HELO at all - but if the client does do a HELO, the restrictions in smtpd_helo_restrictions would still apply, as you've found.

Jenny D
  • 27,358
  • 21
  • 74
  • 110
  • 1
    Thank you for the answer. Actually I thought about removing this... but isn't this a security threat in anyway? That's why I was reluctant to doing it. What do you think? – The Quantum Physicist Sep 02 '15 at 14:20
  • 1
    It's a spam prevention issue rather than a security threat. You may reduce the amount of spam a little by keeping it in, but you're also likely to lose some legitimate mail. I've found that using greylisting is a far more effective spam deterrent than checking HELO resolvability. – Jenny D Sep 02 '15 at 14:24
  • Thank you. Am I using any greylisting? What is that? Could you please provide a reference? – The Quantum Physicist Sep 02 '15 at 14:28
  • From the configuration you've posted, you don't appear to be using it. It means that the first time that someone connects and tries to send an email, your server will give a temporary error, and then remember the sending IP address, the FROM and the TO. The next time the sender connects with those same IP, FROM and TO, the email will be allowed. Many spammers use botnets that just pump spam through and don't have any code for handling temporary errors, so those mails will never show up. Legitimate mail will come through, but they will be delayed by several minutes. – Jenny D Sep 02 '15 at 14:31
  • Have a look at http://serverfault.com/questions/419407/fighting-spam-what-can-i-do-as-an-email-administrator-domain-owner-or-user for more info about what you can do. The postfix documentation site (http://postfix.org) has information about setting up greylisting. Your config also shows that you're using RBLs, this will of course also cut down on spam. (When I started antispam work 20 years ago, we worried that there'd be so much spam that email would be unusable within a few years... I'm glad we were wrong on that, but sad that so much spam is still around!) – Jenny D Sep 02 '15 at 14:35
9

You can change your HELO policy to:

smtpd_helo_restrictions = 
    permit_mynetworks,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    reject_unknown_helo_hostname

...and add your home mail server's address to mynetworks = ... line.

Although the answer by @JennyD is valid and should solve your problem, it can be better to keep your current HELO policy for external hosts. This has an advantage: misconfigured MTAs won't be able to send messages to your server, which will save you from some spam (although rather a little bit). Anyway, hosts with improper HELO configuration are to be suspected.

Going a bit further, make sure you have at least reject_unknown_client_hostname among the list under ie. smtpd_client_restrictions = .... This will prevent messages from MTA hosts without proper reverse DNS record and thus many botnet relays. Another important antispam measure would be SPF policy deamon (ie. milter-greylist) and, obviously, SpamAssassin.

sam_pan_mariusz
  • 2,053
  • 1
  • 12
  • 15
2

If you don't have fine grained control over clients, you should be using SASL anyway:

smtpd_delay_reject = yes

smtp_helo_restrictions =
    permit_sasl_authenticated,
    reject_unknown_helo_hostname

This allows SASL authenticated hosts to send a helo without restriction

Note that in some configurations, master.cf sets smtp_helo_restrictions for both submission and smtps to $mua_helo_restrictions, so in that case set mua_helo_restrictions instead.

nyet
  • 131
  • 4
  • This didn't work for me. What works is: smtpd_helo_restrictions = permit_sasl_authenticated – ChristophK Oct 17 '18 at 11:01
  • THIS worked for me: adding **permit_sasl_authenticated** ! `smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unknown_helo_hostname, reject_non_fqdn_helo_hostname` – simUser May 26 '21 at 11:25