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

[swbrains]

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 <[email protected][my server hostname].com>

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]

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, [<MYIPADDRESS>]
         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, [<MYIPADDRESS>]
         250-SIZE 157286400
         250-8BITMIME
         250-ENHANCEDSTATUSCODES
         250-PIPELINING
         250-CHUNKING
         250 SMTPUTF8
  SMTP>> MAIL FROM:<> SIZE=4777
  SMTP>> RCPT TO:<[email protected]>
  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 [<MYIPADDRESS>   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

 

[swbrains]

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.

 

[cPanelLauren]

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:<[email protected]>

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)