5

On a postfix MTA MX setup, I have a spam mail pass two checks which it definitely shouldn't.

The postfix/smtpd process logs these warnings, which should be a hard fail in this setup:

  • hostname * does not resolve to address *: No address associated with hostname
  • Unable to look up MX host * for Helo command *: No address associated with hostname

The relevant mail log is this:

postfix/smtpd: warning: hostname peggy-langley.colormemobile.com does not resolve to address 45.58.139.69: No address associated with hostname
postfix/smtpd: connect from unknown[45.58.139.69]
postfix/smtpd: warning: Unable to look up MX host mail.intrcomm.net for Helo command eldoark.com: No address associated with hostname
policyd-spf: prepend Received-SPF: Neutral (mailfrom) identity=mailfrom; client-ip=45.58.139.69; helo=eldoark.com; [email protected]; receiver=<UNKNOWN>
postgrey: action=greylist, reason=new, client_name=unknown, client_address=45.58.139.69, [email protected], recipient=<hidden>
postfix/smtpd: NOQUEUE: reject: RCPT from unknown[45.58.139.69]: 450 4.2.0 <hidden>: Recipient address rejected: Greylisted, try again later; from=<[email protected]> to=<hidden> proto=ESMTP helo=<eldoark.com>

This should not even hit greylisting, or the further checks which would block it later.
Here is why:

  • 45.58.139.69 has a PTR record peggy-langley.colormemobile.com, but this domain has no A/AAAA IP record (nor an MX record).
  • The HELO of eldoark.com has an MX record of mail.intrcomm.net, but this subdomain has no A/AAAA IP records.

I can't find any postconf setting that would turn these warnings into errors, and I wonder if I'd have to write my own check there.
postfix does log warnings, it is aware of the issues, so hopefully I'm simply missing something?


The MTA config has

smtpd_delay_reject = yes    
smtpd_helo_required = yes
smtpd_helo_restrictions =
    [...]
    reject_unknown_helo_hostname,
    [...]
    permit

and

smtpd_sender_restrictions =
    [...]
    reject_unknown_sender_domain,
    [...]
    permit

and I would have thought that either one or both should nuke this connection, but on closer look, those checks seem to be insufficient here:

reject_unknown_helo_hostname: Reject the request when the HELO or EHLO hostname has no DNS A or MX record.

Clearly, the HELO domain has an A and MX record (only the MX fails to resolve). So this seems to pass.

reject_unknown_sender_domain: Reject the request when Postfix is not final destination for the sender address, and the MAIL FROM domain has 1) no DNS MX and no DNS A record, or 2) a malformed MX record such as a record with a zero-length MX hostname

MAIL FROM ([email protected]) is clearly spoofed, so this doesn't help at all?

edit: Added requested SMTP transcript, for what's it worth

Out: 220 my.domain.name ESMTP Postfix
In:  EHLO eldoark.com
Out: 250-my.domain.name
Out: 250-PIPELINING
Out: 250-ETRN
Out: 250-STARTTLS
Out: 250-ENHANCEDSTATUSCODES
Out: 250-8BITMIME
Out: 250-DSN
Out: 250 SMTPUTF8
In:  MAIL FROM:<[email protected]> BODY=8BITMIME
Out: 250 2.1.0 Ok
In:  RCPT TO:<hidden>
Out: 450 4.2.0 <hidden>: Recipient address rejected:
     Greylisted, try again later
In:  QUIT
Out: 221 2.0.0 Bye

2 Answers 2

4

From #postfix@freenode IRC, I've gotten the helpful hint (thanks, JPT) that the connecting IP/hostname is, of course, checked in smtpd_client_restrictions.

smtpd_client_restrictions =
    [...]
    reject_unknown_reverse_client_hostname,
    [...]

My existing reject_unknown_reverse_client_hostname entry only checks for a missing client IP address address->name mapping! I've now replaced it with the stricter reject_unknown_client_hostname check which should "eliminate" the first warning:

reject_unknown_client_hostname: Reject the request when 1) the client IP address->name mapping fails, or 2) the name->address mapping fails, or 3) the name->address mapping does not match the client IP address.

Postfix doesn't seem to provide a reject option for the second warning: postfix/smtpd: warning: Unable to look up MX host mail.intrcomm.net for Helo command eldoark.com: No address associated with hostname.

Perhaps that makes sense, I can't say off the top of my hat. (To be clear: If there is no MX host, only an A record, that is valid and acceptable to me, but an MX host that points to nirvana shouldn't be accepted? If someone knows a config to enforce that, I'd love to know.)

edit: main Issue resolved:

postfix/smtpd[13599]: warning: hostname extremetech.com does not resolve to address 23.94.113.133
postfix/smtpd[13599]: connect from unknown[23.94.113.133]
postfix/smtpd[13599]: NOQUEUE: reject: RCPT from unknown[23.94.113.133]: 450 4.7.25 Client host rejected: cannot find your hostname, [23.94.113.133]; from=<[email protected]> to=<hidden> proto=ESMTP helo=<lapolla.com>
postfix/smtpd[13599]: disconnect from unknown[23.94.113.133] ehlo=1 mail=1 rcpt=0/1 data=0/1 quit=1 commands=3/5
2
  • I was getting log message "warning: hostname * does not resolve to address * " accompanying spam delivery. I tried the fix above which looks like it should solve the problem, but it also blocks email from other servers, that did not have the above warning, with log message " * said: 550-Requested action not taken: mailbox unavailable 550 invalid DNS MX or A/AAAA resource record (in reply to MAIL FROM command))" Again the above message is from a server that was sending without warnings prior to fix. Any ideas?
    – MindSpiker
    Commented May 4, 2022 at 2:34
  • Ignore above comment. It was unrelated to the issue in this post. oops
    – MindSpiker
    Commented May 11, 2022 at 0:43
0

It's hard to tell without seeing the entire log for this SMTP transaction, but Postfix won't actually reject a message until after the client has sent the RCPT TO command. It may know that it's going to reject but won't actually do so. Reason being, some clients will not check to see if the message has been rejected during the transaction and continue to try to deliver so connections will be longer than needed.

If you set smtpd_delay_reject = no then Postfix will reject as soon as the rule is evaluated. I'm not really sure if that's a good idea or not.

Without seeing the entire config, it's hard to tell what's going on here.

3
  • I don't see how the SMTP transaction could help here, but I added it. The postfix config is long and complex; I've tried to include the relevant parts, but if you ask for something specific perhaps, I can add it.
    – nyov
    Commented Dec 5, 2019 at 21:10
  • Sorry, I probably wasn't clear. I was talking about the entire snippet of the server log pertaining to this message. It's possible that is the complete log and I just always had my logging turned up and dumped to syslog. I assumed you only included parts that you thought were relevant, but I could be wrong. What I was getting at was since postfix won't reject the message until after the RCPT TO command, I thought you just didn't see the rejection notice. But I would think it would show up instead of the greylist rejection or at least alongside it. Commented Dec 6, 2019 at 1:46
  • Okay, my postfix isn't set to debug logging, and there was no TLS connection, so I added postfix' reject line, but then this is all there was from this smtpd process. I removed the syslog timestamp and process pids as irrelevant. I seem to have solved it though. But thank you very much for taking the time to create an account and answer, it's appreciated.
    – nyov
    Commented Dec 6, 2019 at 16:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .