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?

Reply to
Dimiter_Popoff
Loading thread data ...

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

Reply to
Joe Gwinn

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.

Reply to
Ricky

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.

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.

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):

formatting link
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!

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)

Reply to
Martin Brown

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.

Reply to
Sylvia Else

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

Reply to
Dimiter_Popoff

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.

I think almost everyone is forcing authentication now.

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:

formatting link
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!

Reply to
Martin Brown

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.

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.

Reply to
Dimiter_Popoff

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.

Reply to
Ricky

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.