Understanding how bounces are processed

[dwalsh0]

Hello,

I'm trying to understand how ZoneMTA handles bounce messages.

My original understanding if the bounce message matches what's in config/bounces.txt it would attempt a redelivery (on a different IP address), but it doesn't seem to be the case, it just goes into deferred and then re-attempts on the same IP that had the issue.

Jul 28 12:59:52 zonemta[4133539]: info Sender/default/4133539[6] id=svd5unyzzguhz22p 1984e8a65b30004db0.001 DEFERRED[network] from=bookings@example.com to=to@example.net src={MYSERVERIP} mx=example.net id=bec241b7-94e5-419a-af9b-c6308d12ec1d@example.com (554 Blocked - see https://ipcheck.proofpoint.com/?ip={MYSERVERIP})

Jul 28 16:59:57 zonemta[4133539]: info Sender/default/4133539[9] id=svd5unyzzguhz22p 1984e8a65b30004db0.001 CONNECTING domain=example.net port=25

Jul 28 16:59:57 zonemta[4133539]: info Sender/default/4133539[9] id=svd5unyzzguhz22p 1984e8a65b30004db0.001 CONNECTED domain=example.net mx=mxa-00680501.gslb.pphosted.com[205.220.185.42] src=reverse[{MYSERVERIP}]

Jul 28 16:59:58 zonemta[4133539]: ERR! Sender/default/4133539[9] id=svd5unyzzguhz22p 1984e8a65b30004db0.001
SMTPERR [0hsxUbalMcA] src={MYSERVERIP} error="Invalid greeting. response=554 Blocked - see https://ipcheck.proofpoint.com/?ip={MYSERVERIP}: 554 Blocked - see https://ipcheck.proofpoint.com/?ip={MYSERVERIP}"

Jul 28 16:59:58 zonemta[4133539]: ERR! Sender/default/4133539[9] id=svd5unyzzguhz22p 1984e8a65b30004db0.001 ERRCONNECT [0hsxUbalMcA] Unexpected MX error. src={MYSERVERIP} error="Invalid greeting. response=554 Blocked - see https://ipcheck.proofpoint.com/?ip={MYSERVERIP}: 554 Blocked - see https://ipcheck.proofpoint.com/?ip={MYSERVERIP}"

Jul 28 16:59:58 zonemta[4133539]: info Sender/default/4133539[9] id=svd5unyzzguhz22p 1984e8a65b30004db0.001 SMTPCLOSE [0hsxUbalMcA] Closed prematurely src={MYSERVERIP} response="554 Blocked - see https://ipcheck.proofpoint.com/?ip={MYSERVERIP}" connected=0.937s.

Looking at the docs more, I can change the sending zone:
delivery.updates.sendingZone = 'someother';

but it means I'd have to use a different block of ips to send from rather than it just not keep sending from the same one. Is there anything around delivery.updates that would allow the IP address be changed if we see deferrals on a single IP address.

[andris9]

If the bounce is detected as blacklisted based on the rules in the config files, then this specific IP is temporarily removed from the pool, and some other IP is used (assuming you have more than 1 IP in the same pool). Otherwise, the same IP is always used, mostly to avoid issues with graylisting etc.

Based on the current ruleset, this response should be classified as blacklist and as such, if you have multiple IP addresses in the same pool, ZoneMTA should not use the same address for sending. Unless all IPs in the pool get flagged as blacklisted in which case the blacklist is treated as regular soft bounce because there are no alternative IPs to fall back to anymore.

$ echo '554 Blocked - see https://ipcheck.proofpoint.com/?ip={MYSERVERIP}' | node ./bin/check-bounce.js
data     : 554 Blocked - see https://ipcheck.proofpoint.com/?ip={MYSERVERIP}
action   : defer
message  : Sender IP blacklisted
category : blacklist
code     : 554
status   : false
line     : 372

In your case, though, this is not a bounce but a block. ZoneMTA can not even open a connection to the MX server; the connection is immediately refused. This is why the regular blacklist handling probably fails.

[dwalsh0]

Thanks for the reply,

That all makes sense, I wonder if we can detect this sort of connection error in a plugin and force a different ip to send?