Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 0 replies
  • Subscribers 1 subscriber
  • Views 4901 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Outbound mail fails with greylisting (no retry)

hagman_01
I see outbound mail fail because of greylisting. Apparently, not enough retries are being made before giveing up. The receiving side seems to behave the way greylisting is suuposed to work, but my astaro makes just a single attempt to one MX of the receiving side - and then it gives up:

2014:11:11-09:26:29 firewall exim-out[7785]: 2014-11-11 09:26:29 1Xo6mS-0001yl-Af Completed
2014:11:11-09:26:29 firewall exim-out[7790]: 2014-11-11 09:26:29 1Xo6mT-0001yl-02 SMTP error from remote mail server after RCPT TO:RECIPIENT@REMOTE.com>: host mx02.MXDOMAIN.de [xx.xx.xx.162]: 450 4.2.0 : Recipient address rejected: Greylisted, see http://postgrey.PROVIDER/help/REMOTE.com.html
2014:11:11-09:26:29 firewall exim-out[7788]: 2014-11-11 09:26:29 1Xo6mT-0001yl-02 == RECIPIENT@REMOTE.com R=dnslookup T=remote_smtp defer (-44): SMTP error from remote mail server after RCPT TO:RECIPIENT@REMOTE.com>: host mx01.MXDOMAIN.de [xx.xx.xx.161]: 450 4.2.0 RECIPIENT@REMOTE.com>: Recipient address rejected: Greylisted, see http://postgrey.PROVIDER/help/REMOTE.com.html
2014:11:11-09:26:29 firewall exim-out[7788]: 2014-11-11 09:26:29 1Xo6mT-0001yl-02 ** RECIPIENT@REMOTE.com: retry timeout exceeded
2014:11:11-09:26:29 firewall exim-out[7792]: 2014-11-11 09:26:29 1Xo6mT-00021g-3C <> R=1Xo6mT-0001yl-02 U=exim P=local S=87053
2014:11:11-09:26:30 firewall exim-out[7788]: 2014-11-11 09:26:30 1Xo6mT-0001yl-02 Completed


How to ensure that mails will be requeued for at least a couple of minutes (which should be normal behaviour anyway)?

EDIT:
I just notice that other outbound mails survive greylisting. In those cases the remote server replied with "451 4.7.1 Greylisting in action,..." instead of "450 4.2.0 ...". Both 450 and 451 are classified as temporary, as is also signalled by the 4.x.x enhanced status code. x.2.x in stead of x.4.x suggests a mailbox problem instead of a network problem, but that should not cause a difference. Interestingly, the working enhanced code 4.7.1 is described in RFC3463 as "This is useful only as a permanent error." All in all, I don't see that I could rightfully tell the remote side that "450 4.2.0" would be wrong ...

EDIT 2:
According to old logs, the same sender-recipient-mailserver-message combination did work fine a week ago!


This thread was automatically locked due to age.
Unfiltered HTML