Is something up with email globally?

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?

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

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

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 

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

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.

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...

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

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.

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