During the last week I have been getting increasing numbers of e-mails 'bouncing'; some would go through at the second or third attempt, others won't go at all.
Typical bounce message copied below, showing that it went to the main recipient but bounced from the copied-in recipient (munged for obvious reasons):
~~~~~~~~~~~~~~
Subject: Mail delivery failed: returning message to sender
Sent: 20220613 20:05
Received: 20220613 20:22
From: Steve Marsh
To: Liz Txx, [email protected]
Enclosures: encoded MIME file.87
Enclosed Text.55
encoded MIME file.88
This is an automatically generated Delivery Status Notification.
Delivery to the following recipients failed permanently:
* [email protected]
Reason: A message that you sent to the following recipient could not be delivered due to a permanent error. ** The remote server ?? responded
with: ** [email protected] ??:?? This message was created
automatically by mail delivery software on the server .
~~~~~~~~~~~~~~
~~~~ encoded MIME file.87 ~~~~
Reporting-MTA: dns; avasout-ptp-001 [84.93.230.227]
Received-From-MTA: dns; [192.168.1.200] [87.112.26.116]
Arrival-Date: Mon, 13 Jun 2022 20:05:28 +0100
Final-recipient: rfc822; [email protected]
Diagnostic-Code: smtp; 550-5.7.1 [84.93.230.227 5] Our system has detected that this message is
Last-attempt-Date: Mon, 13 Jun 2022 20:05:29 +0100
~~~~~~~~~~~~~~
~~~~ Enclosed Text.55 ~~~~
Received: from [192.168.1.xxx] ([87.112.26.xxx])
by smtp with SMTP
id 0pNOoOvgvCVxY0pNPoUYnJ; Mon, 13 Jun 2022 20:05:28 +0100 X-Clacks-Overhead: "GNU Terry Pratchett"
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.4 cv=ENUVbnVC c=1 sm=1 tr=0 ts=62a78a78
a=KN0HsOjmyYcFGF2m1DToHw==:117 a=KN0HsOjmyYcFGF2m1DToHw==:17
a=HpEJnUlJZJkA:10 a=kj9zAlcOel0A:10 a=7JSo8fN662x8P3BE00cA:9 a=CjuIK1q_8ugA:10
Subject: Re: File formats
Date: Mon, 13 Jun 22 20:04:42 +0100
x-mailer: Claris Emailer 1.1
From: Liz <[email protected]>
To: "Mxx Txx" <[email protected]>
cc: "Dxx Hxx (BOA)" < [email protected]>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-CMAE-Envelope: MSxxfJTd9s+TiG/jYscKw48uV0t54Ky9WNCR/ZxyHa2DMSiOiOG3n5D0+eMZALxDfa1gHhPz y7YQ/lXBYcJsAo+L+HpNFrYzD0u45DUbX72jNo8TrgCXzCTI
SVV8tCw+2S/XbkFOhN5Pn3pwVItqdTaEBqV+lkLlto6Z5nEvyfFR0=2IcWZ47gguErBcYYSi A+mBeX7QR5QBNoJIPXcDotcC 6rSB
~~~~~~~~~~~~~~~
~~~~ encoded MIME file.88 ~~~~
Received: from [192.168.1.xxx] ([87.112.26.xxx])
by smtp with SMTP
id 0pNOovCVxY0OvgpNPoUYnJ; Mon, 13 Jun 2022 20:05:28 +0100 X-Clacks-Overhead: "GNU Terry Pratchett"
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.4 cv=ENUVbnVC c=1 sm=1 tr=0 ts=62a78a78
a=KN0HsOjmyYcFGF2m1DToHw==:117 a=KN0HsOjmyYcFGF2m1DToHw==:17
a=HpEJnUlJZJkA:10 a=kj9zAlcOel0A:10 a=7JSo8fN662x8P3BE00cA:9 a=CjuIK1q_8ugA:10
Subject: Re: File formats
Date: Mon, 13 Jun 22 20:04:42 +0100
x-mailer: Claris Emailer 1.1
From: Liz <[email protected]>
To: "MxTx" <[email protected]>
cc: "Dxx Hxx (BOA)" < [email protected]>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-CMAE-Envelope: MS4xfJ/jYscKUbX72jTiGNw48uV0t5R/ZxGHa2DMSiOiOG3gHhPzy7YQ/lXBYcJsAo+L+HpN FrYzD0u45Do4Ky9WNC8TrgCXzCTIn5D0+eMZALxDfa1 Td9s
2IcWZ47gguErlkLltoBcYYSiAmBeX7QR5QBNoJIPXcDotcC+2S/XbkFOhN5Pn3pwVItqdTaE BqV+6Z5nEv6rSBSVV8tCwyfFR0=
[ original text ]
~~~~~~~~~~~~~~~~~~~~
Any idea what is happening and what I can do about it?
Liz Tuddenham <[email protected]d> wrote:
During the last week I have been getting increasing numbers of e-mails
'bouncing'; some would go through at the second or third attempt, others
won't go at all.
Typical bounce message copied below, showing that it went to the main
recipient but bounced from the copied-in recipient (munged for obvious
reasons):
~~~~~~~~~~~~~~
Subject: Mail delivery failed: returning message to sender
Sent: 20220613 20:05
Received: 20220613 20:22
From: Steve Marsh
To: Liz Txx, [email protected]
Enclosures: encoded MIME file.87
Enclosed Text.55
encoded MIME file.88
This is an automatically generated Delivery Status Notification.
Delivery to the following recipients failed permanently:
* [email protected]
Any idea what is happening and what I can do about it?
I wonder if it’s anything to do with the gmail authentication changes made recently.
Any idea what is happening and what I can do about it?I wonder if it’s anything to do with the gmail authentication changes made recently.
<https://support.google.com/accounts/answer/6010255?hl=en>
On 13/06/2022 20:58, Alan B wrote:
Any idea what is happening and what I can do about it?I wonder if it’s anything to do with the gmail authentication changes made
recently.
<https://support.google.com/accounts/answer/6010255?hl=en>
No, not that specific change. But a 550 response from Gmail means they
think your ISP is a home for spammers.
There's some info here <https://support.google.com/mail/answer/188131>
but Liz's first port of call should be her ISP. Chances are they know
and are already working on it but it might be a few days for the block
to clear. In other words, wait a few days and try again.
Bruce Horrocks <[email protected]> wrote:
On 13/06/2022 20:58, Alan B wrote:
Any idea what is happening and what I can do about it?I wonder if it’s anything to do with the gmail authentication changes made
recently.
<https://support.google.com/accounts/answer/6010255?hl=en>
No, not that specific change. But a 550 response from Gmail means they
think your ISP is a home for spammers.
I'm sending from Plusnet.
Liz Tuddenham wrote:
Bruce Horrocks <[email protected]> wrote:
On 13/06/2022 20:58, Alan B wrote:
Any idea what is happening and what I can do about it?I wonder if it’s anything to do with the gmail authentication changes made
recently.
<https://support.google.com/accounts/answer/6010255?hl=en>
No, not that specific change. But a 550 response from Gmail means they
think your ISP is a home for spammers.
I'm sending from Plusnet.
That probably explains it.
The smtp; 550-5.7.1 [84.93.230.227] response is from one of your
recipient's email servers ); which says your message comes from a server
(at IP 84.93.230.227) that has a bad reputation for sending spam. Since Plusnet probably has many SMTP servers with different IP addresses not
every message you send will suffer the same issue.
Graham J <[email protected]> wrote:
Liz Tuddenham wrote:
Bruce Horrocks <[email protected]> wrote:
On 13/06/2022 20:58, Alan B wrote:
Any idea what is happening and what I can do about it?I wonder if it’s anything to do with the gmail authentication >>>>>changes made
recently.
<https://support.google.com/accounts/answer/6010255?hl=en>
No, not that specific change. But a 550 response from Gmail means they >>>>think your ISP is a home for spammers.
I'm sending from Plusnet.
That probably explains it.
The smtp; 550-5.7.1 [84.93.230.227] response is from one of your >>recipient's email servers ); which says your message comes from a server >>(at IP 84.93.230.227) that has a bad reputation for sending spam. Since >>Plusnet probably has many SMTP servers with different IP addresses not >>every message you send will suffer the same issue.
I’m slightly surprised at that as Plusnet has been part of the BT empire >for some time. Perhaps its reputation predates the takeover?
Liz Tuddenham wrote:
Bruce Horrocks <[email protected]> wrote:
On 13/06/2022 20:58, Alan B wrote:
Any idea what is happening and what I can do about it?I wonder if it’s anything to do with the gmail authentication changes made
recently.
<https://support.google.com/accounts/answer/6010255?hl=en>
No, not that specific change. But a 550 response from Gmail means they
think your ISP is a home for spammers.
I'm sending from Plusnet.
That probably explains it.
The smtp; 550-5.7.1 [84.93.230.227] response is from one of your
recipient's email servers ); which says your message comes from a server
(at IP 84.93.230.227) that has a bad reputation for sending spam.
Bruce Horrocks <[email protected]> wrote:
On 13/06/2022 20:58, Alan B wrote:
Any idea what is happening and what I can do about it?I wonder if it’s anything to do with the gmail authentication changes made
recently.
<https://support.google.com/accounts/answer/6010255?hl=en>
No, not that specific change. But a 550 response from Gmail means they
think your ISP is a home for spammers.
I'm sending from Plusnet.
On 13/06/2022 22:23, Liz Tuddenham wrote:
Bruce Horrocks <[email protected]> wrote:
On 13/06/2022 20:58, Alan B wrote:
Any idea what is happening and what I can do about it?I wonder if it’s anything to do with the gmail authentication changes made
recently.
<https://support.google.com/accounts/answer/6010255?hl=en>
No, not that specific change. But a 550 response from Gmail means they
think your ISP is a home for spammers.
I'm sending from Plusnet.
PlusNet has been caught up in this sort of thing before on a couple of occasions. It did get sorted but it looks as if it's happening again.
On 14 Jun 2022 at 09:01:08 BST, Graham J <[email protected]> wrote:
Liz Tuddenham wrote:
Bruce Horrocks <[email protected]> wrote:
On 13/06/2022 20:58, Alan B wrote:
Any idea what is happening and what I can do about it?I wonder if it’s anything to do with the gmail authentication changes made
recently.
<https://support.google.com/accounts/answer/6010255?hl=en>
No, not that specific change. But a 550 response from Gmail means they >>>> think your ISP is a home for spammers.
I'm sending from Plusnet.
That probably explains it.
The smtp; 550-5.7.1 [84.93.230.227] response is from one of your
recipient's email servers ); which says your message comes from a server
(at IP 84.93.230.227) that has a bad reputation for sending spam.
In whose opinion? And what has it to do with them anyway?
Your only solution is to buy an email service from a reputable supplier,
so that you send your emails directly to their SMTP server (thus
avoiding Plusnet's sever).
On 14 Jun 2022 at 09:01:08 BST, "Graham J" <[email protected]> wrote:
Your only solution is to buy an email service from a reputable supplier,
so that you send your emails directly to their SMTP server (thus
avoiding Plusnet's sever).
She can't avoid using a PlusNet IP address if that is her ISP, whichever email
service is used.
She can't avoid using a PlusNet IP address if that is her ISP,
whichever email service is used.
Rubbish.
Liz can use the Plusnet IP to communicate with her email provider.
In order to send an email her mail client will first have to
authenticate with her email provider, usually by account name &
password. The emails she sends go into the email provider's server,
from which they are sent on to their intended recipients.
So far as the recipients (or their email service providers) are
concerned Liz's emails are shown as coming from her email provider.
Ray wrote:
On 14 Jun 2022 at 09:01:08 BST, "Graham J" <[email protected]> wrote:
Your only solution is to buy an email service from a reputable supplier, >>> so that you send your emails directly to their SMTP server (thus
avoiding Plusnet's sever).
She can't avoid using a PlusNet IP address if that is her ISP,
whichever email
service is used.
[snip]
Rubbish.
Liz can use the Plusnet IP to communicate with her email provider.
In order to send an email her mail client will first have to
authenticate with her email provider, usually by account name &
password. The emails she sends go into the email provider's server,
from which they are sent on to their intended recipients.
So far as the recipients (or their email service providers) are
concerned Liz's emails are shown as coming from her email provider.
Indeed, you'd be submitting your messages directly to the email
provider, so that's the entity that is transferring the mail onwards.
So Plusnet could potentially interfere by blocking the outbound
submission port. You'd likely be safe configuring your client to use dedicated submission ports on the email provider (the standard is 587, historically 2525 and 465 have also been used) and not just port 25. You
look spammier if you try to submit on 25.
TimS wrote:
On 14 Jun 2022 at 09:01:08 BST, Graham J <[email protected]> wrote:
Liz Tuddenham wrote:
Bruce Horrocks <[email protected]> wrote:
On 13/06/2022 20:58, Alan B wrote:
Any idea what is happening and what I can do about it?I wonder if it’s anything to do with the gmail authentication changes made
recently.
<https://support.google.com/accounts/answer/6010255?hl=en>
No, not that specific change. But a 550 response from Gmail means they >>>>> think your ISP is a home for spammers.
I'm sending from Plusnet.
That probably explains it.
The smtp; 550-5.7.1 [84.93.230.227] response is from one of your
recipient's email servers ); which says your message comes from a server >>> (at IP 84.93.230.227) that has a bad reputation for sending spam.
In whose opinion? And what has it to do with them anyway?
Prudent email services check where email comes from, using services such
as https://spamrl.com/
If messages come via a server listed there, said prudent services will
reject it out of hand.
Now it turns out that one of the servers belonging to the people who develop SQLite3 has been blacklisted by one of these self-appointed outfits. Seems to me that so-called "prudent email services" are hardly prudent at all.
On 17 Jun 2022 at 15:03:56 BST, "TimS" <[email protected]> wrote:
Now it turns out that one of the servers belonging to the people who develop >> SQLite3 has been blacklisted by one of these self-appointed outfits. Seems to
me that so-called "prudent email services" are hardly prudent at all.
They're demonstrating their prudence. Look:
Servers get blacklisted because they've demonstrated themselves to be
spam source/relay.
So either their mailserver itself is compromised, or
the admins are lax enough they let spam through from some other
compromised host.
Either way, they get on the list. Which is as it should be. Other email services choose whether or not to subscribe to the various Lists Of
Spammers.
Most do, because they don't want to receive or relay spam themselves,
and nor do their users wish to receive it.
People can get their servers off the lists by asking nicely with
evidence they've fixed their shit. Or by fixing their shit and letting
their ban time out.
On 17 Jun 2022 at 23:52:05 BST, Jaimie Vandenbergh <[email protected]> wrote:
On 17 Jun 2022 at 15:03:56 BST, "TimS" <[email protected]> wrote:
Now it turns out that one of the servers belonging to the people who develop
SQLite3 has been blacklisted by one of these self-appointed outfits. Seems to
me that so-called "prudent email services" are hardly prudent at all.
They're demonstrating their prudence. Look:
Servers get blacklisted because they've demonstrated themselves to be
spam source/relay.
Not always. They can also get blacklisted by having an IP address, or perhaps a /24, which is part of a larger block which is entirely
blacklisted because it contained *another* /24 which was used by the naughty boys.
TimS wrote:
On 17 Jun 2022 at 23:52:05 BST, Jaimie Vandenbergh
<[email protected]> wrote:
On 17 Jun 2022 at 15:03:56 BST, "TimS" <[email protected]> wrote: >>>>
Now it turns out that one of the servers belonging to the people who develop
SQLite3 has been blacklisted by one of these self-appointed outfits. Seems to
me that so-called "prudent email services" are hardly prudent at all.
They're demonstrating their prudence. Look:
Servers get blacklisted because they've demonstrated themselves to be
spam source/relay.
Not always. They can also get blacklisted by having an IP address, or perhaps
a /24, which is part of a larger block which is entirely
blacklisted because it contained *another* /24 which was used by the naughty >> boys.
[snip]
The blackisting services will probably respond to a request for
de-listing where an explanation like this can be provided.
TimS wrote:
On 17 Jun 2022 at 23:52:05 BST, Jaimie Vandenbergh
<[email protected]> wrote:
On 17 Jun 2022 at 15:03:56 BST, "TimS" <[email protected]> wrote: >>>>
Now it turns out that one of the servers belonging to the people who develop
SQLite3 has been blacklisted by one of these self-appointed outfits. Seems to
me that so-called "prudent email services" are hardly prudent at all.
They're demonstrating their prudence. Look:
Servers get blacklisted because they've demonstrated themselves to be
spam source/relay.
Not always. They can also get blacklisted by having an IP address, or perhaps
a /24, which is part of a larger block which is entirely
blacklisted because it contained *another* /24 which was used by the naughty >> boys.
[snip]
The blackisting services will probably respond to a request for
de-listing where an explanation like this can be provided.
Did not take that as final though, since the ability to mail people is paramount for account management. Some digging later it turns out that our server sending the email got blocked courtesy of said SCI company for sending emails (and getting complained) from an IP what is not a registered mail server. (Since when is that a requirement?)
This was easier to solve by simply registering our server as a mail-server with them (perhaps other "SCI" type companies have the same), though I'll say that that required a whole registration form with quite some details being filled in - something I wasn't happy about, but they know they have you at their mercy and you can do nothing about it.
On 18 Jun 2022 at 16:21:31 BST, "TimS" <[email protected]> wrote:
Did not take that as final though, since the ability to mail people is
paramount for account management. Some digging later it turns out that our >> server sending the email got blocked courtesy of said SCI company for sending
emails (and getting complained) from an IP what is not a registered mail
server. (Since when is that a requirement?)
This was easier to solve by simply registering our server as a mail-server >> with them (perhaps other "SCI" type companies have the same), though I'll say
that that required a whole registration form with quite some details being >> filled in - something I wasn't happy about, but they know they have you at >> their mercy and you can do nothing about it.
This reads suspiciously like "Oh no I have to follow the rules of the
road in order to drive".
On 19 Jun 2022 at 14:08:03 BST, Jaimie Vandenbergh <[email protected]> wrote:
On 18 Jun 2022 at 16:21:31 BST, "TimS" <[email protected]> wrote:
Did not take that as final though, since the ability to mail people is
paramount for account management. Some digging later it turns out that our >>> server sending the email got blocked courtesy of said SCI company for sending
emails (and getting complained) from an IP what is not a registered mail >>> server. (Since when is that a requirement?)
This was easier to solve by simply registering our server as a mail-server >>> with them (perhaps other "SCI" type companies have the same), though I'll say
that that required a whole registration form with quite some details being >>> filled in - something I wasn't happy about, but they know they have you at >>> their mercy and you can do nothing about it.
This reads suspiciously like "Oh no I have to follow the rules of the
road in order to drive".
But as I keep saying, in some instances no rules have been broken. What you then have is a Kafka-esque situation to navigate.
First you have to talk to
your mail addressee's ISP, with whom you have no business relationship, and who is therefore not obliged to talk to you. You have to hope they tell you which organisations have blacked your IP. You then have to hope these entities
will give you the time of day, which people's experience seems to show they will not.
In fact there are no rules. Just arbitrary decisions taken by some entities.
On 19 Jun 2022 at 14:08:03 BST, Jaimie Vandenbergh <[email protected]> wrote:
On 18 Jun 2022 at 16:21:31 BST, "TimS" <[email protected]> wrote:
Did not take that as final though, since the ability to mail people is
paramount for account management. Some digging later it turns out that our >>> server sending the email got blocked courtesy of said SCI company for sending
emails (and getting complained) from an IP what is not a registered mail >>> server. (Since when is that a requirement?)
This was easier to solve by simply registering our server as a mail-server >>> with them (perhaps other "SCI" type companies have the same), though I'll say
that that required a whole registration form with quite some details being >>> filled in - something I wasn't happy about, but they know they have you at >>> their mercy and you can do nothing about it.
This reads suspiciously like "Oh no I have to follow the rules of the
road in order to drive".
But as I keep saying, in some instances no rules have been broken. What you then have is a Kafka-esque situation to navigate. First you have to talk to your mail addressee's ISP, with whom you have no business relationship, and who is therefore not obliged to talk to you.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 714 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 141:17:57 |
| Calls: | 12,087 |
| Files: | 14,998 |
| Messages: | 6,517,442 |