Rejection/bounce notice from server can't be delivered back to sender

swbrains

• June 10, 2020 23:12

I have a strange issue that I can't figure out. A hosted site sends out an email to a number of users. A few of their addresses are invalid or mailboxes are full, so the server tries to send a "Mail delivery failed: returning message to sender" message back to the sender. But these notices back to the sender get "frozen" in the queue because they have trouble being delivered. Eventually they disappear from the queue, but I don't see them listed in the delivery report history, so I'm not sure if they get delivered or dumped. The strange part is that the rejection notices fail to be delivered back to the sender (with a valid address) due to a strange error. When I try to force delivery of the reject notice back to the sender, it looks like there is an initial error due to some type of unencrypted communcation during the first attempt to connect: LOG: MAIN cwd=/usr/local/cpanel/whostmgr/docroot 4 args: /usr/sbin/exim -v -M 1jjDVI-0003eH-P0 delivering 1jjDVI-0003eH-P0 LOG: MAIN Unfrozen by forced delivery LOG: MAIN Sender identification U=mailnull D=-system- S=mailnull Connecting to mx.[snipped].com [snipped IP]:25 ... connected SMTP<< 220 bosimpinc12 bizsmtp ESMTP server ready SMTP>> EHLO [snipped] SMTP<< 250-bosimpinc12 hello [snipped], pleased to meet you 250-HELP 250-SIZE 30000000 250-8BITMIME 250-STARTTLS 250 OK SMTP>> STARTTLS SMTP<< 220 Ready to start TLS SMTP(close)>> LOG: MAIN TLS session: (SSL_connect): error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol: delivering unencrypted to H=mx.[snipped].com [snipped IP] (not in hosts_require_tls) Transport port=25 replaced by host-specific port=25
Then it appears to try again... Connecting to mx.[snipped].com [snipped IP]:25 ... connected SMTP<< 220 bosimpinc12 bizsmtp ESMTP server ready SMTP>> EHLO [snipped].com SMTP<< 250-bosimpinc12 hello [snipped IP], pleased to meet you 250-HELP 250-SIZE 30000000 250-8BITMIME 250-STARTTLS 250 OK SMTP>> MAIL FROM:<> SIZE=5104 SMTP<< 550 <> Sender rejected. SMTP>> QUIT SMTP(close)>> LOG: MAIN ** [snipped]@[snipped].com R=dkim_lookuphost T=dkim_remote_smtp H=mx.[snipped].com[snipped IP]: SMTP error from remote mail server after MAIL FROM:<> SIZE=5104: 550 <> Sender rejected. LOG: MAIN Frozen (delivery error message)
So, it seems like there are two problems here: 1) The first attempt has some issue based on the message: "unsupported protocol: delivering unencrypted to H=mx.[snipped].com [snipped IP] (not in hosts_require_tls)" 2) The second attempt is really the one that confuses me: "SMTP error from remote mail server after MAIL FROM:<> SIZE=5104: 550 <> Sender rejected." I'd appreciate any advice on #1, but I'm really curious as to why the receiving server is rejecting the message in #2 based on "MAIL FROM:<>" / "<> Sender rejected." When I view the rejection notice sitting the queue and click the icon to view the message details, it shows the FROM: header as From: Mail Delivery System
So wouldn't that be a valid non-blank sender? Yet, during the delivery attempt, the SMTP FROM line is sent as: MAIL FROM:<> SIZE=5104, and the error returned from that server is 550 <> Sender rejected. Why does my server not send over a FROM address, or if it does, why does the receiving server not recognize it? Thanks in advance for any clarification or advice anyone can provide!

• 

  cPanelLauren

  • June 16, 2020 01:58

  I don't think the MAIL FROM has anything to do with this on my own server it does the same after the STARTTLS session: LOG: MAIN Sender identification U=mailnull D=-system- S=mailnull Connecting to gmail-smtp-in.l.google.com [172.217.197.26]:25 ... connected SMTP<< 220 mx.google.com ESMTP n197si10020737qke.28 - gsmtp SMTP>> EHLO server.myserver.us SMTP<< 250-mx.google.com at your service, [] 250-SIZE 157286400 250-8BITMIME 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-CHUNKING 250 SMTPUTF8 SMTP>> STARTTLS SMTP<< 220 2.0.0 Ready to start TLS SMTP>> EHLO server.myserver.us SMTP<< 250-mx.google.com at your service, [] 250-SIZE 157286400 250-8BITMIME 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-CHUNKING 250 SMTPUTF8 SMTP>> MAIL FROM:<> SIZE=4777 SMTP>> RCPT TO: SMTP>> DATA SMTP<< 250 2.1.0 OK n197si10020737qke.28 - gsmtp SMTP<< 250 2.1.5 OK n197si10020737qke.28 - gsmtp SMTP<< 354 Go ahead n197si10020737qke.28 - gsmtp SMTP>> writing message and terminating "." SMTP<< 550-5.7.1 [ 19] Our system has detected that this message is 550-5.7.1 likely suspicious due to the very low reputation of the sending 550-5.7.1 domain. To best protect our users from spam, the message has been 550-5.7.1 blocked. Please visit 550 5.7.1 https://support.google.com/mail/answer/188131 for more information. n197si10020737qke.28 - gsmtp SMTP>> QUIT SMTP(close)>>
  Now my mail was blocked but it's not because of the MAIL FROM: it's because google has decided for some reason my domain I'm using has poor sending reputation - most likely because this is a test server. The other error is a protocol error - the connection attempt being made during STARTTLS is using the SSLv2.3 protocol rather than a usable protocol (TLSv1.2) but it falls back to unencrypted

  0
• 

  swbrains

  • June 16, 2020 03:49

  Thanks. I guess the reason its seems odd to me is because in my case the final attempt that fails receives this response from the receiving server during delivery: SMTP>> MAIL FROM:<> SIZE=5104 SMTP<< 550 <> Sender rejected.
  which makes me think the receiving server really is rejecting the message because the sender is blank.

  0
• 

  cPanelLauren

  • June 16, 2020 07:02

  They just don't have a pretty rejection notice for the specific rejection they're providing you. Your sender is being rejected (but not for that reason) in my case the transaction is allowed to proceed. As you can see in my output it's identical for the sender: SMTP>> MAIL FROM:<> SIZE=4777 SMTP>> RCPT TO:
  The only difference being the rejection reason. While I can't be sure this is the case here there are quite literally servers that block bounces - based on the fact they're rejecting the specific email account it sounds like that's the case (and without the ability to attempt to connect to the server via telnet)

  0

Please sign in to leave a comment.