Sent emails bounced with 'Nemesis' problem

[#1]

---

@steve_arnold wrote:

Unfortunately still not working for me, I've done some checking and apparently my ip in the 80.229.x.x range is on the Spamhaus Zen PBL list,

Steve

---

All dynamic IP addresses will be on various blocklists, and this applies to all ISPs. That's to help users of blocklists stop spam due to botnets use of smtp services on infected computers. Using the ISP smarthost (in this case relay.plus.net) should be fine.

There is actually nothing to remove.

[#2]

Hi, 

My IP is a static one that I've had for all the years I've been with Plusnet.

Steve

[#3]

Both end-user dynamic and static IPs are on the PBL This reflects the

Outbound Email Policy of Plusnet Plc for (the relevant) IP range:

It is the policy of Plusnet Plc that unauthenticated email sent from this IP address should be sent out only via the designated outbound mail server allocated to Plusnet Plc customers. To find the hostname of the correct mail server to use, customers should consult the original signup documentation or contact Plusnet Plc Technical Support.

If using deep parsing of Received headers the guidance from Spamhaus is that reference to the PBL is *not* appropriate. If GMX do such deep parsing and respect that advice discussion of PBL content becomes irrelevant.

[#4]

Hi Folks

All's that's been discussed is the same as my problem; same error situation, same error message.

So as my NAS is configured to send through relay,plus.net then the problem is not my end, yes?  Am I right in thinking that to the recipient (and their mail account) my mail server is not in question?  Are the recipients' servers parsing too deeply or is relay.plus.net 'untrustworthy'?

I don't use the 'offending' email address much but when I do I need reliability.

So what's next then?

Andy  

[#5]

Yes, that's correct. the recipient mail server should make whatever checks it wishes to do against the transmitting MTA (Mail Transfer Agent). This will be an avasoutNN.plus.net with matching IP for external MTAs. NN represents two digits. Normally the reputations of these servers is good and Plusnet would take action to fix the problem if any got blacklisted. Transmitting MTA IPs will never appear in the PBL (Policy Block List).

For internal recipients transmitting MTA IP reflects an infrastructure path, but that should never be an issue.

If receiving MTAs choose to do deeper parsing of Received headers, and check the Received header for the mail submission agent, care is needed. The content of that depends on which agent is used. Thunderbird provides the internal IP address whereas Outlook 2016 provides the computer name. These are accompanied by the WAN IP of the external connection. The reverse and forward DNS entries for WAN IPs normally match as far as I'm aware, but the IPs are likely to appear in the PBL because they should *not* be contacting external mail servers directly. 

When using an internal mail server smart-hosting via relay.plus.net that internal server becomes the submission agent onto the WAN.

[#6]

---

@spraxyt wrote:

When using an internal mail server smart-hosting via relay.plus.net that internal server becomes the submission agent onto the WAN.

---

David,

You seem to be hinting at something deeper here...

There is a difference between an email client SUBMITTING a message to a SMTP relay server (should be done on port 587) and one MTA RELAYING a message to another relay server (should be done on port 25).

I'm not conversant with all of the detail, however does the above imply that where a user is running their own email server, if their local email clients have the local email server configured as their SMTP host, any email sent out WILL appear to have originated from their external IP address, even if their mail server relays via relay.plus.net ?  Is this at the heart of this issue?

Would the correct configuration here be to (on the email client) configure relay.plus.net as the SMTP server, rather than the local email server?

[#7]

Without knowledge of the complete Received headers trace and which servers (including the remote MX) and clients do what I think we are heading too far into the realms of speculation.

[#8]

I was about to start my own thread on this but realise I am a /metoo for this exact problem.

For about a week now emails sent to myself on my mail.com address (owned by United Internet and also run alongside gmx.com) have bounced with exactly the same sort of message:

Reporting-MTA: dns; avasout08 [212.159.14.20]
Received-From-MTA: dns; EXCHANGE1.something.co.uk [62.0.0.0]
Arrival-Date: Mon, 19 Feb 2018 12:47:12 +0000


Final-recipient: rfc822; robx@mail.com
Diagnostic-Code: smtp; 554-mail.com (mxgmxus005) Nemesis ESMTP Service not available

Last-attempt-Date: Mon, 19 Feb 2018 12:47:12 +0000

I earlier raised a ticket with support so hopefully they will be able to shed some light on whether this is something deep under the bonnet on relay.plus.net or gmx's filtering.

Last week I did raise a query with mail.com but I may as well have been speaking in the glagolitic alphabet from the patronising reply I got back. I will progress this if the consensus is that it's a change from GMX rather than plus.

rgds

Rob

[#9]

No response yet to my follow up to GMX, as a interesting aside the notification email for this thread was treated as spam by the Plusnet spam filtering....

Steve

[#10]

Just sent a message from another of my Plusnet mailboxes using Thunderbird and it was delivered successfully, obviously they trust avasout01.plus.net for the moment at least.

Header from the received email:

Return-Path: <xxx@xxxxx.plus.com>
Received: from avasout01.plus.net ([84.93.230.227]) by mx-ha.gmx.net (mxgmx011 [212.227.15.10]) with ESMTPS (Nemesis) id 0MK5NV-1eoi672q9N-001PiO for <xxxxx@gmx.co.uk>; Mon, 19 Feb 2018 22:47:42 +0100
Received: from [192.168.1.100] ([80.229.xxx.xxx]) by smtp with ESMTP id ntHheZYTUZqItntHie4JcR; Mon, 19 Feb 2018 21:47:42 +0000
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.3 cv=C7LHNzH+ c=1 sm=1 tr=0 a=PAEqQyJP2UmHTn95Mvzntw==:117 a=PAEqQyJP2UmHTn95Mvzntw==:17 a=IkcTkHD0fZMA:10 a=_50KkayP4TGAo18EnyMA:9 a=QEXdDO2ut3YA:10
To: xxxx <xxxxx@gmx.co.uk>
From: xxxx <xxxx@xxxx.plus.com>
Subject: test from another mailbox
Message-ID: <9a30efc8-9440-da7d-25e1-121136c9205a@xxxxx.plus.com>
Date: Mon, 19 Feb 2018 21:47:41 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-CMAE-Envelope: MS4wfAmHKKwVrnAKdQ7PHJI1OroiaQWl9AHgv01VzWhB/ootYygJ5oCjfjEtBHP64HFMPEsPqjL9Lh1C3juhuR8AcpJIrDO2QH3yXoABau6xCGklUCf8bXKR eSilyhm9fbdbsYK+H5w2wRne9rEAplmipzrMhK0PeUkLOh6kDPEcTjR2rXxyvWAHkvfj9H0c+tMqNw==
Envelope-To: <xxxx@gmx.co.uk>
X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=V3;
X-UI-Filterresults: notjunk:1;V01:K0:LauHIxMsFGY=:GYe9tonLisLRnEXuTobC1bGrW8 fQCQV97gxac2KkQvzxGSrY1pZylsvnrJXijA98b/zHztlZt9dm9cTxPBSb7XSBAAONlbqscM0 cuTqcuO6zywTRAJYJ/wsNeziKTbcgppaDjwHg+3JKiDLl5IRkCbJHyG0t0V1NKF6MDDxw8vZF aIPAUAc6V2qr0/+85g+BKfnyxwIGKJPAriIQWmViBCv02uk/WfCrrCqGYzWBnFM+bxf2FsayH +yeIXUSH7U0iFvcbIeGf7TMb5Y33/bZilPYEmtVriZsFYLme+WTTjIs8PNYAENo0u7yFE/Tir cvufeFEoaRvSaZC8ovQa5vQzfQgouIixmQMzpPYrrsu36+oiV4PoPHWWzw/t7Mo292NxZ8JGh TaEVXZfLhwbkUwvRYg6Ii+xm4kmfNhQIiQlWq7MQbD6dSUpq00MATRBWJmKAqZF+ns8E+ZWiR RIGS6Z5gBwCoEvibnj2WIF/VbjRugvIknvGe8TW4OSLm1u4OyksFGvRYAN7Fy8c/J2DrKeBti dr1d96WpKWh4CU+1Ee92BjixUnZkXcYL+PTO2kHi8Z/yfmk6SUzY/Q0biTGK8kbNHgCH2GGbc OzubvfId1NDq4Zz+MejZtIeiaXFeNZKtzGlhQsrqLUdieJAdLyiNg+FyIcwl/cW3GoFs86gPj eyns3qRVwC9qESvEFqySw9znDAY+qcTrBDiZLWZgwHWBaEFBBTxbrYXMb280Pi1+ZlcSpmPIt BBCOcpQX6YgxdJJ68riZx/+kCBE9P4ACfCa6u/rMj+a85iT3nMPU4fuN8BbsW/fEmSgJvNmMU pi6xMXXPs13oOwQSB3rdhYRcUMTvb8cgyzTJsTNNxCtah1jPg1TnllXDcTusjPWD3QupEM8MI jJYzpFoZrNxRhpojnV1oKSdEqFQXCYsetNCPTnE01vLwNUfwdOFhDTWlnl0V20Xs/Hfsw56PS gBfj6UZ/fzK628nhgaMD9zs8Y3ALAmr/Hnj0YZxFKxao4xIwr74v2iUg6msMmP8x9I8SaF0/g 7QebulD7iMPwKB6CoZoMsYZmXWGn/O9Hhfy/vY6bb1rtePvhZQ8k28zB7QpVkumFCcK+VxU3y fZ044srq2vumvR3mN34BUCkwqNFZCQdpVuYE0JpW0HnU5MTcIU3Gu1+/lDRvs2oX0sgUFQuTn d2oP4BMHqB67z5zFRBOXAX8V5Mdx9AIAZsf+ZuCUeCp0rHBR7suL8kGf1kcVV0GjoHGW7rOik 6lMFDFC7t1eS/0KLfTtAwoxufuYf+3GtVc33icMdvkuYSs5Lk717V/PCnY7MfExneqFGNCi66 Z4b8ePDhqmiZLrO9EEVMpS5sH9HpUHa2dhr4l6UKhg1Qeja2PtaSTXW1lvi+bC/EDL6oyFNTb +8xfiJtUKATUTCMF+1Q+V6I94rk+REFX5/yDUMi7fjmz6flsFb3zhGuWJhySZuP4D/mxN/ZL3 HJaB3DZ7Boo/v0ub8tgEHkgSQhvhoK2lt7A/mqmm7C/XRHQXjQkM8rGyzZhrqKYOp9avszCKw iauCFItnfv15YVxFTxC/nzfncVba1GUQHKTMDsdjMSwKBpIfY7g5NgY2W1YEkoI8bAsBi3zFu J1/R8EQD0vuGH3QJMjPz3EgFNgInhmm2DW87OdRFzZ8GUot9yDCAN8yQCTg7f23TN4k8bkDLX DaLKsn9GXhQ1KYWZEzzuWEz36px2qsMETPZ+czRKY6UQTpMp44d5YBVfDbWvPbrIkdixspXO+ o0VhgQ6wry7HUJwM/4Ayf6a/ASipeb+MubWQ==

Steve

[#11]

---

@steve_arnold wrote:

Just sent a message from another of my Plusnet mailboxes using Thunderbird and it was delivered successfully, obviously they trust avasout01.plus.net for the moment at least.

While the GMX server is in a good mood could you try sending a message from the mailbox which failed to see if it still does?

[#12]

Have done so and to my surprise it was received however the headers show it was directed via avasout01.plus.net .

Steve

[#13]

Hi Folks

I've just tried with my mail.com client and it failed with the same Nemesis message.

Don't know if that helps or hinders!

Andy

[#14]

My outgoing always seem to go through AVASOUT08 and very occasionally AVASOUT02. And always fail.

Anyway I have had a couple of responses from mail.com/GMX and they are just stalling - asking for "complete headers" from the bounce email which I have already sent twice. No ownership yet taken from plus or GMX.

So we're on our own, together

Hopefully some more constructive news later

[#15]

Reply from GMX:

Thank you for the detailed message.

We have forwarded your message to our Security Department, they are getting in touch with Plusnet in order to identify the problem.
I will then inform you when I receive more information on the issue.

We hope for your understanding and patience.

Best regards,
Romina / GMX International Support