![]() I see that it does rewrite the return path but crudely, just to your Zoho mailbox, not an SRS implementation. I saw the mention above of Zoho by went to check it out. I came here after hearing elsewhere of the SPF issues. Hopefully PN are monitoring this thread and can look into it. Plusnet are currently handling it as a hard fail, but that just might be how they choose to handle that particular situation. In your SPF record, you have a tilde in the ~all part, meaning that the SPF record shouldn't prevent the mail being delivered even if it fails the SPF check - it should only be a "soft fail". On a side note, the same manager said that it looks like Plusnet might be bouncing those messages incorrectly. ![]() ![]() I can't give any specifics because I just don't know, but it's more likely to be months rather than weeks.Īlso this, not sure if it is "good" information: Realistically, that means that whilst we might implement it in the future, it's not going to happen for a while. He says that it's possible to do, but it's not a quick thing to implement. I've spoken with one of our technical managers regarding SRS and he's looked into implementing SRS. Most pertinent to this thread, I found this: Ok, I've been on the FH forum where there's a long thread about SPF failures, and one of the posters has given them a hard time about their failing. In the meantime, I've concluded I have to disable spam filtering at PN and am now braced for the deluge In the meantime I would hope that PN can introduce the SPF enforcement, which I would support in general terms, in a more user-friendly way. I will take this up with FH on the basis they should support accepted standards aimed at reducing spam and fraud, the more complaints they get the more chance there is of fixing their system. Me: from the error message, I gather that there is a Sender Policy Framework validation failure, does this mean you don't support that or is it the other way round? Most of my email gets through okįH: You need to somehow disable the spam detection on your plusnet's account instead for the forwarded email to bypass the validation.įH: Nothing we can do on Fasthosts server at the moment to meetup the settings in place with plusnet's server. Names have been changed to protect the participants.įH: plusnet have updated their system on validating incoming emails on their server which is not supported with Fasthosts. As others have said, it is not good service to implement a change that was bound to break customers email without warning.įor the record, here's the text of my chat session with Fasthosts which confirms their hands-off approach to the matter. The second link "here" sets out best practice which to me indicates there are some options for Plusnet to adopt in an environment where there are bound to be forwarders that don't comply with SPF. Stuart Gathman's opinion is recorded at and updated here.Ī whitelist seems to me an option, PN runs them as it is, see my initial expereince above. If receivers are going to check SPF, they should whitelist forwarders that do not rewrite the sender address from SPF checks. Yes, but only if the receiver checks SPF without understanding their mail receiving architecture. Having retired I've managed to forget what I knew about the subtleties (like SPF) of mail systems, but the website has some guidance: Both denied responsibility - but the real failure was communication and it seemed that my threat of a conference call with the responsible people was required to get them to sort it out between them. I thought it was a recurrence of an identical issue I had 5 yrs ago with PN and Fasthosts where PN didn't have all of FH email servers in their whitelist, and FH hadn't told them about new servers.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |