Errors recieving mails from this board

Hello,

recieving mails from this board show me some issues:

Code:
    SMTP    #21138 - [162.217.113.110] Error: 550 5.7.1 Forged HELO hostname detected    Heute, 19:15:14
    SMTP    #21138 - [162.217.113.110] MAIL (transaction rejected due to forged HELO hostname, gy8x.x.rootbsd.net != alai.FreeBSD.org)    Heute, 19:15:14
    SMTP    #21138 - [162.217.113.110] MAIL FROM:<forum-bounces+bee3430f+mail=XXXXX@forums.FreeBSD.org> SIZE=5199    Heute, 19:15:14
    SMTP    #21138 - [162.217.113.110] EHLO alai.FreeBSD.org    Heute, 19:15:14
    SMTP    #21138 - [162.217.113.110] Connected    Heute, 19:15:11

So it looks like some errors on the configuration of the mail server of this board.

Regards Thomas
 
Make sure you can do a reverse lookup on whatever the domain name for your mailserver is.

gy8x.x.rootbsd.net != alai.FreeBSD.org
 
Reverse lookups are fine, it's supposed to work like that.

Code:
dice@maelcum:~ % dig alai.freebsd.org +short
162.217.113.110
dice@maelcum:~ % dig -x 162.217.113.110 +short
gy8x.x.rootbsd.net.
dice@maelcum:~ % dig gy8x.x.rootbsd.net +short
162.217.113.110

So it looks like some errors on the configuration of the mail server of this board.
Nope. It's your mailserver that's too strict.
 
Nope. It's your mailserver that's too strict.
Mostly spammers are sending with wrong helo name, so that's the reason for it. And the same are configured on a lot of providers I know.

So in my case I whitelisted the IP - but not every user can do this (if using not his own server) ;)
 
What if I have two outgoing mailservers hiding behind the same NAT'ed IP address? I can name quite a few valid reasons why the HELO resolves to an IP and that IP doesn't resolve back to the same HELO string. It's perfectly fine if you flag it but the mail server should still accept it.
 
The EHLO and HELO hostname string must be the rDNS record of the outgoing address. The HELO/EHLO string is independent and it's not connected to the actual hostname of the server and can be easy changed on the sending server. In this case the sending server should send HELO alai.FreeBSD.org so the rDNS check can match it's IP address to the actual DNS record.

p.s. you can have cluster of outgoing servers with different hostnames but all of them should respond with the rDNS record of they NAt'ed IP or must have unique IP address with rDNS record for each of them if you want to send different HELO.

p.s.2 so in this case rDNS must be changed to match the DNS record OR the server HELO must be changed to match the rDNS (ptr) record
 
Code:
dice@maelcum:~ % dig sirdice.nl MX +short
10 mail.sirdice.nl.
dice@maelcum:~ % dig mail.sirdice.nl +short
185.10.51.26
dice@maelcum:~ % dig -x 185.10.51.26 +short
armitage.sirdice.nl.
dice@maelcum:~ % dig armitage.sirdice.nl +short
185.10.51.26

Never had a problem with this. Mailserver identifies (HELO/EHLO) with mail.sirdice.nl. Note how mail.sirdice.nl ends up being armitage.sirdice.nl. Which is a similar situation as with alai.freebsd.org.
 
It's specified by RFC 5321 under 3.2. Client Initiation.
It isn't, 3.2 talks about when to use HELO or EHLO. There's nothing stated about the identification. Besides that doesnotexist.example.com is a valid hostname. It doesn't resolve but that doesn't change the validity of the hostname.
 
it's up to the server configuration if this identity is required and used for filtering or not.
Sure, I could also configure my mailserver to reject everything that's sent to me. But then the mailserver is going to be somewhat useless. It's perfectly fine if you insist on using draconian filtering but you need to realize you are also going to block perfectly valid emails. Like I said, it's perfectly fine if you flag certain issues, but you should still accept them nonetheless, err on the side of caution as they say. Malware or spam filtering is better done at some other point in the process.
 
It's perfectly fine if you insist on using draconian filtering but you need to realize you are also going to block perfectly valid emails.
Also you have to be aware that with such an unfavorable configuration you might not be able to deliver mails...

I don't know how all provider over the world are handling this. But I can say in Germany the most of the biggest providers are blocking every mail if reverse != ehlo hostname. There're the requirements mostly very strict.
This is a good way to block bad traffic with as little load as possible. Most of the spammers sending spam or phishing mails using proxies and have this mismatch.

For me it's not a problem, if I miss a mail I can whitelist affected servers I want to recieve mails. If someone can't send me mails - it's not my problem if he think it's a good configuration.

However, it should be noted that this also affects users who do not have their own server and are dependent on their provider. These users may not be able to receive the mails at all...
 
Back
Top