Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

The problem seems to be the MS Outlook 2007 not sending SMTP AUTH for some strange reason for only one specific domain.

I run iRedMail server (it's using stock debian 7/wheezy, postfix 2.9.6-2) for my domain and few dozens of client domains. The problem is I have a client unable to send email to myself (not just my email but the whole domain) - it gets rejected due reject_non_fqdn_helo_hostname but the client is using SMTP AUTH and has it correctly set, so it should bypass the FQDN check. It just looks like the MUA is not using SMTP AUTH only for my and my coleaques email addresses.

Has anyone seen this before? How can I workaround this problem? Any input is highly appreciated!

Could it be it's connected to MUA? She is using Outlook (not Express)?

Have a look on following snips of logs showing different situations. All was catched in the same configuration/same MUA/IP's, ...:

1) this is OK: My client sends email to third party server; using SMTP AUTH

May 28 13:02:13 email2 postfix/smtpd[1191]: connect from <censored>
May 28 13:02:13 email2 postfix/smtpd[1191]: 28A5D35E61DC: client=<censored>, sasl_method=LOGIN, sasl_username=<client1@1.example.com>
May 28 13:02:26 email2 postfix/cleanup[1435]: 28A5D35E61DC: message-id=<006c01ce5b92$d33805e0$79a811a0$@cz>
May 28 13:02:44 email2 postfix/qmgr[376]: 28A5D35E61DC: from=<client1@1.example.com>, size=4392922, nrcpt=7 (queue active)
May 28 13:02:44 email2 postfix/smtp[1580]: 28A5D35E61DC: to=<someone@thirdparty.example.com>, relay=127.0.0.1[127.0.0.1]:10024, delay=32, delays=31/0/0/0.88, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as B061435E61DE)
May 28 13:02:47 email2 postfix/qmgr[376]: 28A5D35E61DC: removed

2) this is OK: My client sends email to local account (hers coleque); she is using SMTP AUTH

May 28 13:06:18 email2 postfix/smtpd[2519]: connect from <censored>
May 28 13:06:18 email2 postfix/smtpd[2519]: 49CE735E61D4: client=<censored>, sasl_method=LOGIN, sasl_username=<client1@1.example.com>
May 28 13:06:18 email2 postfix/cleanup[429]: 49CE735E61D4: message-id=<007201ce5b93$5df069c0$19d13d40$@cz>
May 28 13:06:19 email2 postfix/qmgr[376]: 49CE735E61D4: from=<client1@1.example.com>, size=10875, nrcpt=1 (queue active)
May 28 13:06:19 email2 postfix/smtp[2295]: 49CE735E61D4: to=<client2@1.example.com>, relay=127.0.0.1[127.0.0.1]:10024, delay=1.6, delays=1.2/0/0/0.43, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as CC61F35E61D7)
May 28 13:06:19 email2 postfix/qmgr[376]: 49CE735E61D4: removed

3) problem, email sent to my account (same server, but different domain), NOT using SMTP AUTH???:

May 28 13:04:38 email2 postfix/smtpd[1433]: connect from <censored>
May 28 13:04:38 email2 postfix/smtpd[1433]: NOQUEUE: reject: RCPT from <censored>: 554 5.7.1 <my_email>>: Recipient address rejected: Invalid HELO/EHLO; Must be a FQDN or an address literal, not 'xxx'; from=<client1@1.example.com> to=<my_address> proto=ESMTP helo=
May 28 13:04:41 email2 postfix/smtpd[1433]: disconnect from <censored>

Part of postfix configuration:

smtpd_sender_restrictions = permit_mynetworks,
                            reject_authenticated_sender_login_mismatch,
                            permit_sasl_authenticated
smtpd_recipient_restrictions = reject_unknown_sender_domain,
                               reject_unknown_recipient_domain,
                               reject_non_fqdn_sender,
                               reject_non_fqdn_recipient,
                               reject_unlisted_recipient,
                               check_policy_service inet:127.0.0.1:7777,
                               check_policy_service inet:127.0.0.1:10031,
                               permit_mynetworks,
                               permit_sasl_authenticated,
                               reject_unauth_destination
smtpd_helo_restrictions = permit_mynetworks,
                          permit_sasl_authenticated,
                          reject_non_fqdn_helo_hostname,
                          reject_invalid_helo_hostname,
                          check_helo_access pcre:/etc/postfix/helo_access.pcre

See output of postconf and cat main.cfg

share|improve this question
1  
The client is not sending a fqdn hostname in the HELO parameter of the smtp dialog. You have two options: set the HELO correct in the client (which can be difficult). For the second option, it would be helpfull if you could post your postfix config, especially the smtpd_recipient_restrictions (if thats what you use). You should have the option that permits authorized senders bevore the fqdn hostname check. –  Isaac May 28 '13 at 12:35
    
I have updated the question with part of postfix config. So I should move permit_sasl_authenticated toward beginning of the checks? What place would you suggest? –  Kamil Šrot May 28 '13 at 12:42
    
I put permit_sasl_authenticated first or second, second if I use permit_my_networks. –  NickW May 28 '13 at 12:47
    
Btw: I would recommend to put all of the restrictions in smtpd_recipient_restrictions. –  Isaac May 28 '13 at 13:19

3 Answers 3

HELO/EHLO happens before the SMTP authentication. If your server is configured with reject_non_fqdn_helo_hostname = yes, it will reject any connection with an invalid hostname before getting to the SMTP AUTH part.

While keeping this rejection will cut down on some spam, it will also block a number of legitimate mails. You should take a closer look at tthe Postfix documentation for reject_invalid_helo_hostname and smtp_helo_restrictions to figure out how you want this to work.

share|improve this answer
    
My smtpd_helo_restrictions are updated in the question. It permits authenticated before the EHLO check? –  Kamil Šrot May 28 '13 at 13:17

Your smtpd_recipient_restrictions are ok under the assumption that all your clients are well behaving. Since they are not (not sending correct HELO), you should at least have something like

smtpd_recipient_restrictions = reject_unknown_sender_domain, 
                               reject_unknown_recipient_domain, 
                               permit_sasl_authenticated, 
                               reject_non_fqdn_sender, 
                               reject_non_fqdn_recipient, 
                               reject_unlisted_recipient, 
                               check_policy_service inet:127.0.0.1:7777, 
                               check_policy_service inet:127.0.0.1:10031, 
                               permit_mynetworks, 
                               reject_unauth_destination

Even better:

smtpd_recipient_restrictions =
    check_recipient_access hash:/etc/postfix/access-recipient-rfc,
    check_client_access cidr:/etc/postfix/access-client,
    check_helo_access hash:/etc/postfix/access-helo,
    check_sender_access hash:/etc/postfix/access-sender,
    check_recipient_access hash:/etc/postfix/access-recipient,
    permit_mynetworks,
    permit_sasl_authenticated, 
    reject_unknown_sender_domain,
    reject_non_fqdn_sender,
    reject_unknown_recipient_domain,
    reject_non_fqdn_recipient,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client ix.dnsbl.manitu.net,
    # greylisting
    check_policy_service inet:127.0.0.1:10023,
    # policyd-weight
    check_policy_service inet:127.0.0.1:12525,
    reject_unauth_destination,
    reject_unverified_recipient,
    permit

Furthermore you should integrate all restrictions in the smtpd_recipient_restrictions. Since HELO comes bevore the SASL authentication, its no use to permit SASL authentication in the smtpd_helo_restrictions.

In general its good practise to use just smtpd_recipient_restrictions, since you can do everything there, it saves you repeating stuff, and the network overhead of connections that would have been terminated after helo is not substantial.

share|improve this answer
    
I'm testing the first version as the quick fix now and will try to migrate to the second version in case everything will go fine. I really appreciate you input! –  Kamil Šrot May 28 '13 at 13:03
    
What is very strange / the problem is here only for my domain, not any other domain hosted on the same server. I greped thru the logs of the whole day and emails are rejected only for my domain. Do you have any idea why? I also don't understand which check did the reject? Pls. help me to understand it... –  Kamil Šrot May 28 '13 at 13:10
    
Maybe you can post all of your main.cf. Did you try the same client with other domains? –  Isaac May 28 '13 at 13:18
    
I put on the bottom of my question output of postconf and copy of main.cf –  Kamil Šrot May 28 '13 at 13:32
    
Thanks. I have updated my answer –  Isaac May 28 '13 at 14:17
up vote 0 down vote accepted

The problem was in the policyd (cluebringer)... it was not seen from the log for the first look, that reject was not from postfix restriction but from the policyd.

Background

I had in cluebringers group internal_domains only my primary domain (after install) and all new domains wasn't there... To solve the problem I decided to empty the internal_domains and everything works as expected now.

Thank you for all your help!

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.