Is something up with email globally?...

[Dimiter_Popoff]

I got a note today from another group member here saying they had
problems sending emails.
My ISP started to block tcp traffic to port 25 recently, after 15+
years of normal service.
The spam I get got down to 0 for hours now, negligible for today;
typically I get hundreds if not thousands of spam emails on
two of my addresses combined.
I tested sending between several of my emails, most hosted differently,
and things worked but for one which has been erratic before; and it
did get the first try, me manually smtp-ing into port 587 (ISP
blocked port 25, remember; and tethering the house from the phone is
a bit more of a hassle).
Messages sent to intentionally invalid email addresses don\'t bounce,
complete silence. The \"Return-path:\" of the messages I send
containing one is replaced by a null path, <>. Formerly I did
not put any return-path in my messages, they came across with
something like <mailman-whatever...>, not an address but bouncing
worked.

Has anyone noticed anything unusual along these lines?

 

[a a]

On Tuesday, 18 October 2022 at 23:52:31 UTC+2, Dimiter Popoff wrote:

I got a note today from another group member here saying they had
problems sending emails.
My ISP started to block tcp traffic to port 25 recently, after 15+
years of normal service.
The spam I get got down to 0 for hours now, negligible for today;
typically I get hundreds if not thousands of spam emails on
two of my addresses combined.
I tested sending between several of my emails, most hosted differently,
and things worked but for one which has been erratic before; and it
did get the first try, me manually smtp-ing into port 587 (ISP
blocked port 25, remember; and tethering the house from the phone is
a bit more of a hassle).
Messages sent to intentionally invalid email addresses don\'t bounce,
complete silence. The \"Return-path:\" of the messages I send
containing one is replaced by a null path, <>. Formerly I did
not put any return-path in my messages, they came across with
something like <mailman-whatever...>, not an address but bouncing
worked.

Has anyone noticed anything unusual along these lines?

gmail is today dead horse
full of spam either in inbox
or in spam folder

Ppl stopped to use, read, write emails
since phone calls are for free

 

[Joe Gwinn]

On Wed, 19 Oct 2022 00:52:23 +0300, Dimiter_Popoff <dp@tgi-sci.com>
wrote:

I got a note today from another group member here saying they had
problems sending emails.
My ISP started to block tcp traffic to port 25 recently, after 15+
years of normal service.
The spam I get got down to 0 for hours now, negligible for today;
typically I get hundreds if not thousands of spam emails on
two of my addresses combined.
I tested sending between several of my emails, most hosted differently,
and things worked but for one which has been erratic before; and it
did get the first try, me manually smtp-ing into port 587 (ISP
blocked port 25, remember; and tethering the house from the phone is
a bit more of a hassle).
Messages sent to intentionally invalid email addresses don\'t bounce,
complete silence. The \"Return-path:\" of the messages I send
containing one is replaced by a null path, <>. Formerly I did
not put any return-path in my messages, they came across with
something like <mailman-whatever...>, not an address but bouncing
worked.

Has anyone noticed anything unusual along these lines?

Many US ISPs have changed the way email is sent and received, in an
attempt to reduce spam. What has been happening recently is that
older versions of TLS (was SSL) have been dropped, as they had been
cracked.

Joe Gwinn

 

[Ricky]

On Tuesday, October 18, 2022 at 6:50:56 PM UTC-4, Joe Gwinn wrote:

On Wed, 19 Oct 2022 00:52:23 +0300, Dimiter_Popoff <d...@tgi-sci.com
wrote:
I got a note today from another group member here saying they had
problems sending emails.
My ISP started to block tcp traffic to port 25 recently, after 15+
years of normal service.
The spam I get got down to 0 for hours now, negligible for today;
typically I get hundreds if not thousands of spam emails on
two of my addresses combined.
I tested sending between several of my emails, most hosted differently,
and things worked but for one which has been erratic before; and it
did get the first try, me manually smtp-ing into port 587 (ISP
blocked port 25, remember; and tethering the house from the phone is
a bit more of a hassle).
Messages sent to intentionally invalid email addresses don\'t bounce,
complete silence. The \"Return-path:\" of the messages I send
containing one is replaced by a null path, <>. Formerly I did
not put any return-path in my messages, they came across with
something like <mailman-whatever...>, not an address but bouncing
worked.

Has anyone noticed anything unusual along these lines?
Many US ISPs have changed the way email is sent and received, in an
attempt to reduce spam. What has been happening recently is that
older versions of TLS (was SSL) have been dropped, as they had been
cracked.

These days spam on my email is a trivial problem. It\'s the phone spam that drives me crazy. But then that\'s a short trip.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

 

[Martin Brown]

On 18/10/2022 22:52, Dimiter_Popoff wrote:

I got a note today from another group member here saying they had
problems sending emails.

They have recently hardened up the rules on SPF compliance starting
about the beginning of this month. Various major players have been
dropping soft fails where the sender has no SPF record to look up.

The major players I know of where stuff still gets through are iCloud
and Gmail. Most obvious big UK ones where it doesn\'t BT & MSO.

My ISP started to block tcp traffic to port 25 recently, after 15+
years of normal service.
The spam I get got down to 0 for hours now, negligible for today;
typically I get hundreds if not thousands of spam emails on
two of my addresses combined.

It is due to them tightening up SPF - but it has done a fair bit of
collateral damage to small businesses that have less than stellar ISPs
and at present no SPF record on their mail server. Even fairly
experienced internet users from way back have been caught out because
the server side fault is not at all obvious at first glance.

I tested sending between several of my emails, most hosted differently,
and things worked but for one which has been erratic before; and it
did get the first try, me manually smtp-ing into port 587 (ISP
blocked port 25, remember; and tethering the house from the phone is
a bit more of a hassle).

MSO fails them by not allocating a msg-ID if the user has no SPF record
on their domain. Googles info isn\'t too bad a starting point but you
will need to make changes according to your own ISP\'s control panel or
toolset. Right now no SPF record on your domain means you can\'t send
email to quite a large fraction of end users.

In addition MSO also altered their login protocol somewhat messing up
Outlook (but not Outlook Express) - at least for the friends whose
machines I looked at because things had mysteriously gone wrong.

The fault is not unlike this one that they say was fixed in 2019 (but in
reality it is back with a vengeance but with a different cause):

https://support.microsoft.com/en-us/office/outlook-2019-sender-email-address-missing-on-reply-and-forwards-37d5875b-acf1-4e5f-aca4-80daa4913e1e

It started gently about the beginning of the month but by last Monday
the fraction of legitmate emails not reaching their destination had
become ridiculous. I saw no announcements about this change. YMMV

If you did please post the summary!

Messages sent to intentionally invalid email addresses don\'t bounce,
complete silence. The \"Return-path:\" of the messages I send
containing one is replaced by a null path, <>. Formerly I did
not put any return-path in my messages, they came across with
something like <mailman-whatever...>, not an address but bouncing
worked.

Has anyone noticed anything unusual along these lines?

Yes. But most of the stuff sent effectively just vanishes into a black
hole only a tiny percentage of old style mail severs send you bounce
messages which are either of the form SPF fail, no msg-ID or 550 5.7.1
(malformed header missing Msg-ID)

Hope this helps - I\'ve had to dig a few people out of this hole.
(checking my logs it seems to really bite about 5th Oct)

--
Regards,
Martin Brown

 

[Sylvia Else]

On 19-Oct-22 8:52 am, Dimiter_Popoff wrote:

I got a note today from another group member here saying they had
problems sending emails.
My ISP started to block tcp traffic to port 25 recently, after 15+
years of normal service.
The spam I get got down to 0 for hours now, negligible for today;
typically I get hundreds if not thousands of spam emails on
two of my addresses combined.
I tested sending between several of my emails, most hosted differently,
and things worked but for one which has been erratic before; and it
did get the first try, me manually smtp-ing into port 587 (ISP
blocked port 25, remember; and tethering the house from the phone is
a bit more of a hassle).
Messages sent to intentionally invalid email addresses don\'t bounce,
complete silence. The \"Return-path:\" of the messages I send
containing one is replaced by a null path, <>. Formerly I did
not put any return-path in my messages, they came across with
something like <mailman-whatever...>, not an address but bouncing
worked.

Has anyone noticed anything unusual along these lines?

Email is decentralised, so there\'s not going to be a day when everything
suddenly changes.

There seems in increasing trend for large email providers to refuse to
accept emails from small email servers. At some point, this may become
an anti-trust issue in the USA.

Sylvia.

 

[Dimiter_Popoff]

On 10/19/2022 11:33, Martin Brown wrote:

On 18/10/2022 22:52, Dimiter_Popoff wrote:
I got a note today from another group member here saying they had
problems sending emails.

They have recently hardened up the rules on SPF compliance starting
about the beginning of this month. Various major players have been
dropping soft fails where the sender has no SPF record to look up.

The major players I know of where stuff still gets through are iCloud
and Gmail. Most obvious big UK ones where it doesn\'t BT & MSO.

My ISP started to block tcp traffic to port 25 recently, after 15+
years of normal service.
The spam I get got down to 0 for hours now, negligible for today;
typically I get hundreds if not thousands of spam emails on
two of my addresses combined.

It is due to them tightening up SPF - but it has done a fair bit of
collateral damage to small businesses that have less than stellar ISPs
and at present no SPF record on their mail server. Even fairly
experienced internet users from way back have been caught out because
the server side fault is not at all obvious at first glance.

I tested sending between several of my emails, most hosted differently,
and things worked but for one which has been erratic before; and it
did get the first try, me manually smtp-ing into port 587 (ISP
blocked port 25, remember; and tethering the house from the phone is
a bit more of a hassle).

MSO fails them by not allocating a msg-ID if the user has no SPF record
on their domain. Googles info isn\'t too bad a starting point but you
will need to make changes according to your own ISP\'s control panel or
toolset. Right now no SPF record on your domain means you can\'t send
email to quite a large fraction of end users.

In addition MSO also altered their login protocol somewhat messing up
Outlook (but not Outlook Express) - at least for the friends whose
machines I looked at because things had mysteriously gone wrong.

The fault is not unlike this one that they say was fixed in 2019 (but in
reality it is back with a vengeance but with a different cause):

https://support.microsoft.com/en-us/office/outlook-2019-sender-email-address-missing-on-reply-and-forwards-37d5875b-acf1-4e5f-aca4-80daa4913e1e


It started gently about the beginning of the month but by last Monday
the fraction of legitmate emails not reaching their destination had
become ridiculous. I saw no announcements about this change. YMMV

If you did please post the summary!

Messages sent to intentionally invalid email addresses don\'t bounce,
complete silence. The \"Return-path:\" of the messages I send
containing one is replaced by a null path, <>. Formerly I did
not put any return-path in my messages, they came across with
something like <mailman-whatever...>, not an address but bouncing
worked.

Has anyone noticed anything unusual along these lines?

Yes. But most of the stuff sent effectively just vanishes into a black
hole only a tiny percentage of old style mail severs send you bounce
messages which are either of the form SPF fail, no msg-ID or 550 5.7.1
(malformed header missing Msg-ID)

Hope this helps - I\'ve had to dig a few people out of this hole.
(checking my logs it seems to really bite about 5th Oct)

So something is going on indeed.
My emailing goes the simplest way, rfc 821/822 like. MIME messages
go through this as well. I don\'t think smtp via port 25 has any
encryption allowed but it has been decades since I last implemented
it for dps which is where my mailing goes. Esmtp does, I saw that
over port 587; fortunately my hosting provider\'s server will talk
also plain smtp over this port (unlike my ISP\'s server, it insists
on encryption).
So I don\'t have much to tell, all I can see is that I\'ll have to
implement tls etc. now, as if I have nothing better to do. The 587
port will work for a while but how long before they kill that one,
too.
Thanks for the info, it explains what I am seeing to a great extent.
Can\'t imagine how spammers got affected by that, I think they were
using mostly port 25 smtp; perhaps all ISPs have suddenly been
told to disable tcp over this port. I was used to see hundreds of
spam messages a day (I view mail in raw mode, convert further only
if necessary, say non-spam images etc.), skipping one took a
keystroke but during that fraction of a second I saw spammers were
using the return-path: line (comes alsways on top of the rfc822 header)
to indicate what the spam was about, so they\'d get the bounced spam
messages sorted in some way...

 

[Martin Brown]

On 19/10/2022 15:31, Dimiter_Popoff wrote:

On 10/19/2022 11:33, Martin Brown wrote:
On 18/10/2022 22:52, Dimiter_Popoff wrote:

Messages sent to intentionally invalid email addresses don\'t bounce,
complete silence. The \"Return-path:\" of the messages I send
containing one is replaced by a null path, <>. Formerly I did
not put any return-path in my messages, they came across with
something like <mailman-whatever...>, not an address but bouncing
worked.

Has anyone noticed anything unusual along these lines?

Yes. But most of the stuff sent effectively just vanishes into a black
hole only a tiny percentage of old style mail severs send you bounce
messages which are either of the form SPF fail, no msg-ID or 550 5.7.1
(malformed header missing Msg-ID)

Hope this helps - I\'ve had to dig a few people out of this hole.
(checking my logs it seems to really bite about 5th Oct)


So something is going on indeed.

Your best chance is to send something to friends on legacy email servers
that still send back bounce messages. Most modern ones do not to avoid
backscatter - which can be disastrous now that people assume emails are
as good as the postal service for delivery (and usually they are).

I was only able to figure it out because out of a very large number of
emails \"sent\" but vanished the odd one (<0.1%) did bounce and examining
the headers allowed me to see what the other end was objecting to.

The other work around that MS suggests is to set a flag in Outlook to
add any extra headers the server demands to make it acceptable. I
haven\'t tried this and I expect it will fail sooner rather than later
even if it works OK at the moment.

My emailing goes the simplest way, rfc 821/822 like. MIME messages
go through this as well. I don\'t think smtp via port 25 has any
encryption allowed but it has been decades since I last implemented
it for dps which is where my mailing goes. Esmtp does, I saw that
over port 587; fortunately my hosting provider\'s server will talk
also plain smtp over this port (unlike my ISP\'s server, it insists
on encryption).
So I don\'t have much to tell, all I can see is that I\'ll have to
implement tls etc. now, as if I have nothing better to do. The 587
port will work for a while but how long before they kill that one,
too.

I think almost everyone is forcing authentication now.

Thanks for the info, it explains what I am seeing to a great extent.
Can\'t imagine how spammers got affected by that, I think they were
using mostly port 25 smtp; perhaps all ISPs have suddenly been
told to disable tcp over this port. I was used to see hundreds of
spam messages a day (I view mail in raw mode, convert further only
if necessary, say non-spam images etc.), skipping one took a
keystroke but during that fraction of a second I saw spammers were
using the return-path: line (comes alsways on top of the rfc822 header)
to indicate what the spam was about, so they\'d get the bounced spam
messages sorted in some way...

I think it is the new feature of dropping SPF soft fails or neutrals
where the sender does not have a valid SPF record that has done for the
spam injectors. Unfortunately it has also caught out a large number of
smaller businesses that rely on their ISP for basic email. This is an
example from one of the UK ISP\'s support page which explains the basics:

https://www.123-reg.co.uk/support/domains/how-do-i-add-an-spf-record-to-my-domain-name/

Unfortunately no-one thought to warn their customers that either of
these changes were coming or if they did the email didn\'t arrive (a
situation which has suddenly become a lot more common as a result).

I have had to generate a couple of SPF records in the past week to get
friends with small businesess back into a sane position. Emails that
just vanish can have a terrible effect on customer relations and sales!

--
Regards,
Martin Brown

 

[Dimiter_Popoff]

On 10/19/2022 19:17, Martin Brown wrote:

On 19/10/2022 15:31, Dimiter_Popoff wrote:
On 10/19/2022 11:33, Martin Brown wrote:
On 18/10/2022 22:52, Dimiter_Popoff wrote:

Messages sent to intentionally invalid email addresses don\'t bounce,
complete silence. The \"Return-path:\" of the messages I send
containing one is replaced by a null path, <>. Formerly I did
not put any return-path in my messages, they came across with
something like <mailman-whatever...>, not an address but bouncing
worked.

Has anyone noticed anything unusual along these lines?

Yes. But most of the stuff sent effectively just vanishes into a
black hole only a tiny percentage of old style mail severs send you
bounce messages which are either of the form SPF fail, no msg-ID or
550 5.7.1
(malformed header missing Msg-ID)

Hope this helps - I\'ve had to dig a few people out of this hole.
(checking my logs it seems to really bite about 5th Oct)


So something is going on indeed.

Your best chance is to send something to friends on legacy email servers
that still send back bounce messages. Most modern ones do not to avoid
backscatter - which can be disastrous now that people assume emails are
as good as the postal service for delivery (and usually they are).

I was only able to figure it out because out of a very large number of
emails \"sent\" but vanished the odd one (<0.1%) did bounce and examining
the headers allowed me to see what the other end was objecting to.

The other work around that MS suggests is to set a flag in Outlook to
add any extra headers the server demands to make it acceptable. I
haven\'t tried this and I expect it will fail sooner rather than later
even if it works OK at the moment.

My emailing goes the simplest way, rfc 821/822 like. MIME messages
go through this as well. I don\'t think smtp via port 25 has any
encryption allowed but it has been decades since I last implemented
it for dps which is where my mailing goes. Esmtp does, I saw that
over port 587; fortunately my hosting provider\'s server will talk
also plain smtp over this port (unlike my ISP\'s server, it insists
on encryption).
So I don\'t have much to tell, all I can see is that I\'ll have to
implement tls etc. now, as if I have nothing better to do. The 587
port will work for a while but how long before they kill that one,
too.

I think almost everyone is forcing authentication now.

I had a brief look at SMTP related rfc-s, plain smtp also allows
for encryption (unlike what I thought...). But not allowing unencrypted
for public servers is non-compliant if I read that right (spent just
a minute or two on it).
Anyway, my hosting provider (ICDsoft, they host tgi-sci.com, have been
doing a great job for may be 20 years now) do know about SPF and have
some long-named key (forgot it already) looking like some base64 encoded
thing plus some text, which is why my outgoing emails seem to reach
most of their addressees. And they allow me to smtp without encryption,
for now.

Thanks for the info, it explains what I am seeing to a great extent.
Can\'t imagine how spammers got affected by that, I think they were
using mostly port 25 smtp; perhaps all ISPs have suddenly been
told to disable tcp over this port. I was used to see hundreds of
spam messages a day (I view mail in raw mode, convert further only
if necessary, say non-spam images etc.), skipping one took a
keystroke but during that fraction of a second I saw spammers were
using the return-path: line (comes alsways on top of the rfc822 header)
to indicate what the spam was about, so they\'d get the bounced spam
messages sorted in some way...

I think it is the new feature of dropping SPF soft fails or neutrals
where the sender does not have a valid SPF record that has done for the
spam injectors. Unfortunately it has also caught out a large number of
smaller businesses that rely on their ISP for basic email. This is an
example from one of the UK ISP\'s support page which explains the basics:

https://www.123-reg.co.uk/support/domains/how-do-i-add-an-spf-record-to-my-domain-name/


Unfortunately no-one thought to warn their customers that either of
these changes were coming or if they did the email didn\'t arrive (a
situation which has suddenly become a lot more common as a result).

I have had to generate a couple of SPF records in the past week to get
friends with small businesess back into a sane position. Emails that
just vanish can have a terrible effect on customer relations and sales!

My outgoing emails stopped having a non-null return-path line since
recently, I have yet to investigate this. While the From: and Reply-to:,
if available, can be used as a return path I have no idea how many - if
any - smtp servers would use these to return mail to.

 

[Ricky]

On Wednesday, October 19, 2022 at 1:10:36 PM UTC-4, Dimiter Popoff wrote:

On 10/19/2022 19:17, Martin Brown wrote:
On 19/10/2022 15:31, Dimiter_Popoff wrote:
On 10/19/2022 11:33, Martin Brown wrote:
On 18/10/2022 22:52, Dimiter_Popoff wrote:

Messages sent to intentionally invalid email addresses don\'t bounce,
complete silence. The \"Return-path:\" of the messages I send
containing one is replaced by a null path, <>. Formerly I did
not put any return-path in my messages, they came across with
something like <mailman-whatever...>, not an address but bouncing
worked.

Has anyone noticed anything unusual along these lines?

Yes. But most of the stuff sent effectively just vanishes into a
black hole only a tiny percentage of old style mail severs send you
bounce messages which are either of the form SPF fail, no msg-ID or
550 5.7.1
(malformed header missing Msg-ID)

Hope this helps - I\'ve had to dig a few people out of this hole.
(checking my logs it seems to really bite about 5th Oct)


So something is going on indeed.

Your best chance is to send something to friends on legacy email servers
that still send back bounce messages. Most modern ones do not to avoid
backscatter - which can be disastrous now that people assume emails are
as good as the postal service for delivery (and usually they are).

I was only able to figure it out because out of a very large number of
emails \"sent\" but vanished the odd one (<0.1%) did bounce and examining
the headers allowed me to see what the other end was objecting to.

The other work around that MS suggests is to set a flag in Outlook to
add any extra headers the server demands to make it acceptable. I
haven\'t tried this and I expect it will fail sooner rather than later
even if it works OK at the moment.

My emailing goes the simplest way, rfc 821/822 like. MIME messages
go through this as well. I don\'t think smtp via port 25 has any
encryption allowed but it has been decades since I last implemented
it for dps which is where my mailing goes. Esmtp does, I saw that
over port 587; fortunately my hosting provider\'s server will talk
also plain smtp over this port (unlike my ISP\'s server, it insists
on encryption).
So I don\'t have much to tell, all I can see is that I\'ll have to
implement tls etc. now, as if I have nothing better to do. The 587
port will work for a while but how long before they kill that one,
too.

I think almost everyone is forcing authentication now.
I had a brief look at SMTP related rfc-s, plain smtp also allows
for encryption (unlike what I thought...). But not allowing unencrypted
for public servers is non-compliant if I read that right (spent just
a minute or two on it).
Anyway, my hosting provider (ICDsoft, they host tgi-sci.com, have been
doing a great job for may be 20 years now) do know about SPF and have
some long-named key (forgot it already) looking like some base64 encoded
thing plus some text, which is why my outgoing emails seem to reach
most of their addressees. And they allow me to smtp without encryption,
for now.

Thanks for the info, it explains what I am seeing to a great extent.
Can\'t imagine how spammers got affected by that, I think they were
using mostly port 25 smtp; perhaps all ISPs have suddenly been
told to disable tcp over this port. I was used to see hundreds of
spam messages a day (I view mail in raw mode, convert further only
if necessary, say non-spam images etc.), skipping one took a
keystroke but during that fraction of a second I saw spammers were
using the return-path: line (comes alsways on top of the rfc822 header)
to indicate what the spam was about, so they\'d get the bounced spam
messages sorted in some way...

I think it is the new feature of dropping SPF soft fails or neutrals
where the sender does not have a valid SPF record that has done for the
spam injectors. Unfortunately it has also caught out a large number of
smaller businesses that rely on their ISP for basic email. This is an
example from one of the UK ISP\'s support page which explains the basics:

https://www.123-reg.co.uk/support/domains/how-do-i-add-an-spf-record-to-my-domain-name/


Unfortunately no-one thought to warn their customers that either of
these changes were coming or if they did the email didn\'t arrive (a
situation which has suddenly become a lot more common as a result).

I have had to generate a couple of SPF records in the past week to get
friends with small businesess back into a sane position. Emails that
just vanish can have a terrible effect on customer relations and sales!

My outgoing emails stopped having a non-null return-path line since
recently, I have yet to investigate this. While the From: and Reply-to:,
if available, can be used as a return path I have no idea how many - if
any - smtp servers would use these to return mail to.

I recall many moons ago that a spammer (or several) used an email address at my domain as the From: field. I would get a few complaints from people being spammed, but much worse were all the bounce replies because the spam was sent to non-existent email addresses. I would get so many emails on some days that my provider would cut me off.

Fortunately, they would use it for a few days and then rotate through someone else\'s email addresses.

Spam sucks, but it sucks a lot worse on the phone than on the computer.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209