Non-Resolving HELO names

[rwcanary]

We have a client that has a source(sender), which when that source sends our client an email it never gets to the client. !Because!, the source (the sender) has a screwed up mail server setup and it answers with the hello of "beetle", which doesn't resolve to anything.

Question: How can I tell Zimbra to make an exception for this non-reversing name, without disabling the the "non-resolving" filter globally. The white list function only trains the amavis filters, but this issue is at the MTA level.

[ArcaneMagus]

Unfortunately you either have this option on and block a ton of mail... spam and non spam messages alike, or you turn this option off and deal with spam another way. There are LOTS of email servers that are improperly configured and respond with only the first part of their host name rather then the proper FQDN.

[rwcanary]

We have a Sendmail server that is sourced by LDAP. It uses the access-list in the LDAP server. On it we always include that domain and it would allow the domain all though it did not resolve the HELO name.

Does Zimbra use the access list on the LDAP server? But then the setup created an LDAP password and I don't know how to get into it. I've seen the CLI to change the password, but I was afraid to change, afraid it would break something.

[ArcaneMagus]

Sorry looks like I forgot to actually specify the option in the config that is blocking that server:
Global Settings -> MTA tab -> Client must greet with a fully qualified hostname (reject_non_fqdn_hostname)

As for an LDAP ACL... I don't think so but you can look. The LDAP root password can be found using this command:

zmlocalconfig -s ldap_root_password

And the root DN I use to connect is

uid=zimbra,cn=admins,cn=zimbra

[rwcanary]

I use GQ for easier browsing, but can't figure out what it is wanting for a base DN and the Bind DN.

[uxbod]

I would highly recommend that your client fixes their MTA ... If they are sending out to other people aswell then I am pretty sure a lot of their email will not be getting delivered.

As that is pretty much a given in Postfix configuration the only thing you could do is add a header check prior to reject_non_fqdn_hostname and if it matches their MTA name accept the email. This would be a real fudge when what should happen is that they make their MTA RFC compliant.

[LMStone]

Originally Posted by rwcanary

We have a client that has a source(sender), which when that source sends our client an email it never gets to the client. !Because!, the source (the sender) has a screwed up mail server setup and it answers with the hello of "beetle", which doesn't resolve to anything.

Question: How can I tell Zimbra to make an exception for this non-reversing name, without disabling the the "non-resolving" filter globally. The white list function only trains the amavis filters, but this issue is at the MTA level.

We run a lot of mail servers in addition to Zimbra, and unfortunately I can tell you there are many, many legitimate email servers that don't HELO with their FQDN.

Consequently, we don't use this test.

Hope that helps,
Mark

[uxbod]

Mark,

It is like somebody sending you a letter and not paying the appropriate postage. Should the recipient pay the difference or the sender ?

Perhaps bouncing with a 450 to start with asking the sender to make their MTA RFC compliant.

[LMStone]

Originally Posted by uxbod

Mark,

It is like somebody sending you a letter and not paying the appropriate postage. Should the recipient pay the difference or the sender ?

Perhaps bouncing with a 450 to start with asking the sender to make their MTA RFC compliant.

It actually isn't like that...

It happens when the MX record is a proxy, load balancing several real mail servers behind it. We see this with Postini and a number of largeISPs with high availability systems.

It's easy to point to a single Exchange server whose admin never set the smtp greeting properly (and they should), especially when Zimbra sets this for us automatically, but blocking email based on a mismatch between the MX record and the HELO will block tons of legitimate email from systems whose admins won't even return your call.

Hope that helps,
Mark

[uxbod]

So much for having standards then Mark And I do take your comments on board and have seen similar but otherwise how do companies learn.