Join Log in
Score:0
avatar Server

What is the meaning of the parameter bounce="false" in a 553 response from a receiving MTA?

in flag
sootsnoot

This a short specific technical question about an exchange between two MTAs. It is derived from this question in Superuser, which is broader and contains some rants about technical support from specific email providers. Below is a highly-sanitized version of log file entries taken from the logs of an outgoing MTA, where 1.2.3.4 is the IP address of the outgoing MTA, and 5.6.7.8 is the IP address of the receiving MTA. The original sender received no bounce message, and the mail was never delivered to the recipient (neither inbox nor spam folder nor trash). I would like to understand the meaning of the bounce="false" parameter in the 553 response from the receiving MTA. (Note that the entries are ordered newest-to-oldest, as shown by the timestamps). Thanks!

20210812 09:29:10.177 core sid="id1" id="id1id2"
    ip="1.2.3.4" action="PERMERR" dstmta="5.6.7.8" age="61" code="553"
    reason="553 5.3.0 198.71.225.36 Your message was rejected for possible spam/virus
    content.Please ask your email provider to visit http://emailadmin.registeredsite.com
    for resolution.\r\n" account="[email protected]""
    fwd="0" bounce="false" mailfrom="[email protected]" fromdomain="sending-example.com"
    recipient_list="[email protected]" todomain="receiving-example.com"
    subject="Sad news" subject_hash="f35ba6823f3a91025f0a495ed7de3b59" script="" script_ip=""

20210812 09:28:09.658 core sid="id1" id="id1id2"
    ip="1.2.3.4" action="ACCEPT" reason="CLEAN" account="[email protected]"
    fwd="0" mailfrom="[email protected]" fromdomain="sending-example.com"
    recipient_list="[email protected]" todomain="receiving-example.com" subject="Sad news"
    subject_hash="f35ba6823f3a91025f0a495ed7de3b59" script="" script_ip=""

Edit 1:

This doesn't really answer the question as asked, but in subsequent support calls with the two email providers involved, there seemed to be some agreement that the receiving MTA that gave the 553 response to the sending MTA was the one that should have sent a bounce message to the envelope sender. However, an agent for the receiving MTA pointed out to me today that their 553 response itself contains a 3rd IP address: 198.71.225.36. And that that address is the one being complained about, and it is in fact blacklisted if you check at the url contained in the message. All this time I hadn't noticed that address as relevant (or even an address, could have been section numbers like 5.3.0 or something). The 1.2.3.4 was the IP address for the server identified by the MX entry in the zone file for the sending domain, so I assumed it was the one that must have been blacklisted! I haven't yet gotten an explanation for the 'bounce="false"' parameter, or which server generated it.

43
0 + 14
Michael Hampton avatar
cz flag
Michael Hampton
You need to identify the MTA software in use. It does not look like anything commonly seen on the network.
1
Reply
in flag
sootsnoot
@Michael Hampton The sending MTA is godaddy, the receiving MTA Network Solutions. I think they both handle lots of email. So it seems a little surprising the log looks "uncommon". The log entries came from godaddy technical support agents who extracted them from their outgoing server logs. Each entry was a single line, I just sanitized the IP addresses and domains and wrapped them to multiple lines with indentation to post here. The 553 with the 'bounce="false"' parameter came from the netsol server. The IP address of that server is owned by Cloudflare. not netsol, which seems odd to me.
0
Reply
Michael Hampton avatar
cz flag
Michael Hampton
Those are both companies, not MTAs. If GoDaddy have written a custom MTA then you should ask them what it means.
2
Reply
in flag
sootsnoot
Okay, I can do that. I was just reacting to your "not commonly seen on the network", in that godaddy and netsol are both pretty common providers. But while the parameter 'bounce="false"' appears in the log from godaddy, it is actually in the 553 response from netsol. I can ask them, too, but would not expect a meaningful response. Finally spoke with a netsol supervisor last night who promised to stay on top of it and give me an update tomorrow. I'll ask him about their MTA and post it here. Thanks!
0
Reply
Michael Hampton avatar
cz flag
Michael Hampton
Netsol? I thought you said these logs came from GoDaddy?
0
Reply
in flag
sootsnoot
Yes, the log entries came from godaddy, recording a conversation their outgoing server, 1.2.3.4, had with netsol's incoming server, 5.6.7.8. I thought the interesting thing was the bounce="false" parameter, which came from netsol's receiving MTA (whose IP address actually belongs to Cloudflare, according ARIN). It shouldn't matter who recorded the log entries, unless you think that godaddy fabricated the exchange :-) So far, I've been unable to get the time of day from netsol, let alone what MTA software they use.
0
Reply
Michael Hampton avatar
cz flag
Michael Hampton
Why do you say that bounce=false came from netsol? It clearly came from GoDaddy.
0
Reply
in flag
sootsnoot
No. That parameter is on the 553 response, which also contains the link to check for why it was detected as spam, and that link goes to a netsol site, where you can enter an IP address and they tell you whether or not they are blocking it. I've done that many times, and it has always replied that the godaddy IP address is not being blocked. Also check the timestamps, the 553 from netsol is about a half second later than the second entry which says the message is clean (godaddy checking the outgoing message).
0
Reply
Michael Hampton avatar
cz flag
Michael Hampton
I think you have misread the log entry. `bounce=false` is not part of netsol's 553 response. That ends at `for resolution.\r\n"`
1
Reply
in flag
sootsnoot
Ahh, I saw the \r\n, but did not realize that marked the end of the response. I thought that each message would begin with a timestamp. I guess that's why they pay you the big bucks! So I guess now I can go back to godaddy and complain about their not issuing a bounce? Or should netsol have issued a bounce to the sender with their 553 response instead of just telling godaddy's MTA about it? The message about asking your email provider to check registered site is clearly intended for the end user rather than the sending MTA.
0
Reply
Michael Hampton avatar
cz flag
Michael Hampton
Well, before you yell too loudly, you should just simply ask them what `bounce=false` means.
1
Reply
in flag
sootsnoot
Okay, I'll do that and report back. Won't be till later, though, as I've got roofers working above me now and can't talk on the phone (or think). New roof after 43 years, got my money's worth...
0
Reply
in flag
sootsnoot
Contacted godaddy. They use exim. The agent said he would check configuration settings to see if there was something he could do to make it bounce back to the sender, and he came up empty. He agreed that with netsol giving the 553 with a message intended for the end user, then they should be the ones sending the bounce. I downloaded the exim source, but while 'find | xargs egrep' found lots of mentions of spam and bounce. I couldn't find anything preparing a message with that parameter in it. Waiting for the netsol supervisor to get in touch. Thanks very much for your help!
0
Reply
Michael Hampton avatar
cz flag
Michael Hampton
Well that's even stranger, because [exim logs do not look anything like that](https://www.exim.org/exim-html-current/doc/html/spec_html/ch-log_files.html). The soup thickens...
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.