Bouncing e-mails

[#1]

Several occurrences. The bounces are between Plusnet customers.

Subject: Mail delivery failed: returning message to sender

Delivery to the following recipients failed permanently:

   * xxxxxxx@xxxxxxplus.com

Reporting-MTA: dns; avasout-peh-004 [212.159.14.20]
Received-From-MTA: dns; [local address] WAN
Arrival-Date: Mon, 23 May 2022 18:41:02 +0100


Final-recipient: rfc822;

xxxxxxx@xxxxxxplus.com

Diagnostic-Code: smtp; 500 command unrecognized

What's the story, Plusnet?

[#2]

It looks like there is a '.' missing between 'xxxxx' and 'plus.com'

[#3]

@jab1 I would put that down to a typo.

@greygit yes there issues do occur from time to time.  I have a system monitor which sends alerts to me via email ("from" myself to myself).  Amongst a stream of such alerts, I will receive message similar to yours occasionally.  I suspect that this is actually a server time out event which the sending software (in my case a systems monitoring package) is not handing properly.

I have never seen this using other email clients - which client are you using?

[#4]

I don't think this is going to be related to any customer e-mail client. The person I correspond to also sees occasional bounces. Totally different hardware and software at each end. The e-mail gets sent with no apparent errors. Some minutes (insert variable number) the bounce is received. SMTP out, POP3 in (which is fairly standard). I've never had a similar 'bounce' when corresponding with another friend on the other side of the world (well, not quite, but definitely outside the domains of Plusnet Towers).

It is something within the Plusnet e-mail server setup/configs as the error is being generated by a server after the mail has been successfully sent. (IMO).

Typos are me I'm only hiding the recipient's e-mail address.

[#5]

---

@greygit wrote:

Typos are me I'm only hiding the recipient's e-mail address.

---

OK - it was just a thought - back to @Townman 😉

[#6]

Any further thoughts? I've got the (very occasional) bounces stored. I've even read RFC822 in attempt to understand why the server is returning that error.

It isn't a client-side time-out as the mail is accepted by the SMTP server using STARTTLS. If it were client-side I'd be seeing an error when sending and it wouldn't get as far as the SMTP server(s). The bounce comes back promptly from the PN mail server. The Cloudmark ratings in returned headers indicate it has a zero spam rate.

The very odd thing is that after editing the message content (with very minor changes) the same message goes through without error. RFC822 is to do with message header standards. The generic failure code might require some debugging traps enabled on the servers. Just a thought.

[#7]

Hi there,

If you can PM me the full bounceback and headers of the original message you've tried to send which was rejected, I'll raise a NetOps task to take a closer look for you. The example would have to be within the last 7 days although ideally as recent as possible, because it can take a few days for NetOps to pick up a task. 

[#8]

done

[#9]

I've a more recent example.

It is between a PN customer and an external.

I can provide the full bounce if required.

Please advise if you require.

It'd obviously be more convenient if the customer could open the problem and do all (or most) of the attachments.

i could provide a bounce here if you prefer.

[#10]

Hi @greygit, could you PM either Lauren or myself with the headers for the bounce message please?

[#11]

Is that the 'part1.3' attachment from the bounced message?

(which has truncated text of the error).

Or I can just PM you the whole plain-text shebbang/bounce. It hardly includes state secrets.