Email changes and non-plusnet mail providers

[#1]

I gather from Plusnet's email that all email with a @User.plus.com address must be sent through relay.plus.net. (If I have understood it correctly).

Does this affect other email providers such as Gmail and BT? I currently send those through their own SMTP server. Will this still be possible after the changes?

Thanks.

[#2]

Hi there.

I can confirm that what you've said is correct. The changes only affect plusnet email addresses.

[#3]

How will this affect domains registered with Plusnet? One of the issues is that there has never been any way to set txt records. 

[#4]

---

@Gandalf wrote:

Hi there.

I can confirm that what you've said is correct. The changes only affect plusnet email addresses.

---

That's not how I read the email, it does not specify PlusNet email addresses only.  It would also make no sense, I could still send from @myuser.plus.com via another server if I was not using PlusNet's network so it doesn't stop any spoofing or whatever it is that PlusNet are getting worried about.

So please confirm that I will still be able to send emails from @mydomain.com via my domain host's SMTP server when using PlusNet's broadband network.

When is the change being implemented?

[#5]

1. @SilverE

It would also make no sense, I could still send from @myuser.plus.com via another server if I was not using PlusNet's network

No you won't, at least not to any recipient whose mail system checks SPF records. Even when not using Plusnet network, in order to guarantee successful delivery from a *.plus.com address you will need to send via relay.plus.net ( using authenticated SMTP )

@iwrconsultancy I believe ( but am not certain!) that this will affect any domains hosted by Plusnet. Hopefully @Gandalf could confirm ? Basically PN .are implementing SPF and will automatically add the TXT records to define the valid MTAs. That's  probably what you needed TXT records for in the first place I guess ?

[#6]

Who actually applies SPF as more than a mild warning? PlusNet tried to and stopped because huge amounts of genuine mail was being bounced, without notification, because large numbers of mail forwarders don't implement SPS forwarding properly. And spammers/scammers walk around SPF as easily as pie, there's no point in relying on it.

But if that is PlusNet's motivation that's fine by me, as long as they're not blocking the relay for non *.plus.com domains - not hosted by PlusNet. So I await a response from @Gandalf

[#7]

@SilverE In any case, SPF is a problematic technology because it malfunctions with redirected messages. When a message is redirected, the From: field doesn't change. Since the redirect is bound to be from a different server, this creates a false SPF fail. Thus, few sites actually use it to reject messages. More often it will just increase the spam score a few points.

A suggestion: (Maybe one for Spamhaus or the like to take up)

A large part of spam results from address harvesting, by 'bots scraping webpages for anything that looks syntactically like an email address. I often wondered if a blocklist of known harvestable email addresses (Call it HBL) could be put together.

Then if your mailserver sees an SPF soft fail on an inbound message, it checks  both the From: and To: fields for an HBL positive. If yes to either field, the message is rejected.

At least that way, an incorrect SPF config causes no immediate problems for the sender, but will result in message rejections if their address has been leaked to the whole world, and hence is likely to be found in spam headers.

Meanwhile if they pointblank insist in posting their address on a  webpage in spite of all the advice not to do that, they will still be able to send mail so long as they have configured SPF correctly.  

Since actual spam is likely to have bad SPF and a harvested From: address, it will suffer a high rejection rate.

It will also discourage the posting of email addresses on webpages, which can only be a good thing

[#8]

---

@iwrconsultancy wrote:

@SilverE In any case, SPF is a problematic technology because it malfunctions with redirected messages. When a message is redirected, the From: field doesn't change. Since the redirect is bound to be from a different server, this creates a false SPF fail. Thus, few sites actually use it to reject messages. More often it will just increase the spam score a few points.

---

That is exactly the kind of issue I was alluding to, and why PlusNet swiftly gave up rejecting SPF fails when their users "educated" them.

But I still need to know if I will still be able to use my domain host's smtp server @Gandalf 

[#9]

@SilverE, if your domain is not with us for hosting then you can use whatever you wish (based on the restrictions your host imposes, if any). If the domain is hosted with us then the restrictions in the email will apply (in the sense you will need to use our outgoing mail server).

[#10]

---

@JOLO wrote:

@SilverE, if your domain is not with us for hosting then you can use whatever you wish (based on the restrictions your host imposes, if any). If the domain is hosted with us then the restrictions in the email will apply (in the sense you will need to use our outgoing mail server).

---

Thank you for that.

It would have helped if your email what been more specific about what is being done, i.e. applying SPF to plus.com etc, not blocking SMTP ports.

There's been a madasafish.com SPF record for years, it's odd this has not been done before for plus.com. I include that in my SPF record in case I do send from my domain via relay.plus.com - I'll update that to plus.com when you publish your SPF record.

[#11]

Am I right to paraphrase the intent of the original PN email as something like:

"As of an undefined date you will not be able to send out emails with a PN reply-to except via relay.plus.net" ?

And only that?

[#12]

---

@iapetus wrote:

I gather from Plusnet's email that all email with a @User.plus.com address must be sent through relay.plus.net. (If I have understood it correctly).

That's right. We'll be adding SPF TXT records to the .plus.com, .free-online.co.uk, .force9.co.uk etc. zones that will specify mail from these addresses must be sent via our relays.

Does this affect other email providers such as Gmail and BT? I currently send those through their own SMTP server. Will this still be possible after the changes?

Not unless you're sending from your .plus.com etc. address i.e. sending from a GMail address through GMail's relays will continue to work as it always has.

@iwrconsultancy wrote:

How will this affect domains registered with Plusnet? One of the issues is that there has never been any way to set txt records. 

Contrary to what @JOLO has said, I'm not sure the changes are being applied to hosted domains 

[#13]

Hi there, that's correct, it means if you're sending mail from a Plusnet address using a 3rd party server you'll need to update the settings to use our relay: https://community.plus.net/t5/Email/How-to-change-your-outgoing-server-on-a-mail-client/td-p/1606155...

[#14]

---

@SilverE wrote:

Who actually applies SPF as more than a mild warning?

---

I suspect most of the Internet do, certainly all the major mail providers that I am aware of.

PlusNet tried to and stopped because huge amounts of genuine mail was being bounced, without notification, because large numbers of mail forwarders don't implement SPS forwarding properly.

As a standalone black-and-white anti-spoofing measure it is very limited, but that is why it tends to be deployed with DKIM and a DMARC policy as not only can this avoid the false-positives of SPF alone but the domain owner can dictate how failures are treated.

 And spammers/scammers walk around SPF as easily as pie, there's no point in relying on it.

SPF is only an anti-spoofing mechanism and when viewed in that light is not at all easy to undermine.

[#15]

Never looked into DMARC that much, but is it any better than SPF or DKIM? Using two unreliable technologies and hoping one of the pair will not give a false rejection, doesn't sound like the way to do a workmanlike job.

DKIM is in any case a difficult system to implement unless you are a corporate site wit your own mail service. It's also quite difficult to tell if it's been configured correctly, or not. If it hasn't you could be causing yourself problems. Which is probably why most sites don't implement it.