plus.net email filter

[#1]

I keep having problems sending email using plus.net. Their SMTP server rejects some messages as spam. Now I'm not sending spam, I'm sending messages I've written. They say that their system rejects messages according to some filters that have been set by their customers. I think this is entirely wrong. They should not be interfering with whatever messages I want to send, just like royal mail. If I were sending spam, or obscene content etc, then by all means tell me to stop and ultimately prosecute me. But unless I'm committing an offence, or perhaps even a breach of their conditions, they shouldn't be interfering with my mail at all.
In the past I've raised trouble tickets and after a lot of to-ing and fro-ing, they've reset the filters to let the message through, but warned me that it might get blocked again in future depending on what users do! In the latest case, they said the same thing but themessage has been sat in the outbox for a couple of weeks now and still hasn't gone.
So does anybody know how this system actually works and how to get plus.net to actually send emails?

[#2]

Outbound email is sent via Cloudmark appliances. I'm assuming that when the attempt to send a message fails it returns a long string of numbers/characters in the error message? If it does then the message you're trying to send is matching one of Cloudmark's spam fingerprint. This is typically caused by the address you're trying to send to/from or a domain, email address or URL in the body of the email having fallen foul of Cloudmark's authority checks.
There's no way to disable outbound spam filtering without using a non-Plusnet SMTP server.
Without the spam filtering in place, you'd find our servers would end up on blacklists pretty frequently. When this happens it prevents every customer we have from sending email to domains that's using said blacklists.

[#3]

Quote from: Bob

Outbound email is sent via Cloudmark appliances. I'm assuming that when the attempt to send a message fails it returns a long string of numbers/characters in the error message?

No, that's one of my gripes. You don't send me a message to say you're rejecting the outbound message, you just reject it. And my MUA (Evolution) just discards that status unless I restart it and make a special effort to look.
Please note that all the other email systems I use do behave in that way. They send me an email telling me there is a problem. It's only your service that behaves this way, in my experience.
As far as I am concerned, you are accusing me of sending spam, and you should do me the courtesy of doing that to my face, and you should have a human check such accusations FIRST, not after the event. I resent the implication that I can't manage my own system well enough to prevent it becoming a bot. And if it has become a bot then you actively need to tell me about it, IMHO, not just silently discard messages.

Quote

If it does then the message you're trying to send is matching one of Cloudmark's spam fingerprint. This is typically caused by the address you're trying to send to/from or a domain, email address or URL in the body of the email having fallen foul of Cloudmark's authority checks.

Then you and Cloudmark need to figure out a way of making sure its fingerprints accurately identify spam and not real live, commercially relevant mail.

Quote

There's no way to disable outbound spam filtering without using a non-Plusnet SMTP server.

I'll be doing that in the not too distant future by finding a different ISP, if I can't find a way around this.

Quote

Without the spam filtering in place, you'd find our servers would end up on blacklists pretty frequently. When this happens it prevents every customer we have from sending email to domains that's using said blacklists.

I appreciate your problem, but you need to find a better solution, IMHO.
Sorry for the rant, but this really pi**es me off.

[#4]

Quote from: djh

Quote from: Bob Outbound email is sent via Cloudmark appliances. I'm assuming that when the attempt to send a message fails it returns a long string of numbers/characters in the error message? No, that's one of my gripes. You don't send me a message to say you're rejecting the outbound message, you just reject it. And my MUA (Evolution) just discards that status unless I restart it and make a special effort to look. Please note that all the other email systems I use do behave in that way. They send me an email telling me there is a problem. It's only your service that behaves this way, in my experience.

Now I'm even more confused. The message will be refused and an 5xx SMTP response presented. There's nothing unusual about this and it's compliant with RFC's. I was under the impression all decent mail clients would return this SMTP rejection at the point of sending? The message won't be 'bounced' because it's never accepted by our servers in the first place. That shouldn't stop an error dialogue being presented when you try sending the message e.g.

An error occurred while sending mail. The mail server responded:  RM4t1l0030P7bZg01M4uD3 message rejected due to spam or virus. If you believe this is in error please login to your portal or contact your ISP support team.. Please check the message and try again.

This is certainly the way Mozilla/Microsoft email clients and our Webmail platform behaves.

Quote from: djh

As far as I am concerned, you are accusing me of sending spam, and you should do me the courtesy of doing that to my face, and you should have a human check such accusations FIRST, not after the event. I resent the implication that I can't manage my own system well enough to prevent it becoming a bot. And if it has become a bot then you actively need to tell me about it, IMHO, not just silently discard messages.

As above, we don't silently discard anything. Our server returns an explicit 5xx response. I'm sure you can understand that it's simply not feasible to have suspect messages checked by a human being:

220 avasout01 smtp relay.plus.net
ehlo relay
250-avasout01 hello [84.93.221.17], pleased to meet you
250-HELP
250-AUTH LOGIN PLAIN
250-SIZE 104857600
250-PIPELINING
250-8BITMIME
250 OK
mail from:<>
250 <> sender ok
rcpt to:<support@plus.net>
250 <support@plus.net> recipient ok
data
354 enter mail, end with "." on a line by itself
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X
.
552 RM6R1l0020P7bZg01M6YLK message rejected due to spam or virus. If you believe this is in error please login to your portal or contact your ISP support team.

Quote from: djh

Quote If it does then the message you're trying to send is matching one of Cloudmark's spam fingerprint. This is typically caused by the address you're trying to send to/from or a domain, email address or URL in the body of the email having fallen foul of Cloudmark's authority checks. Then you and Cloudmark need to figure out a way of making sure its fingerprints accurately identify spam and not real live, commercially relevant mail.

No anti-spam solution can claim 100% accuracy.

Quote from: djh

Quote There's no way to disable outbound spam filtering without using a non-Plusnet SMTP server. I'll be doing that in the not too distant future by finding a different ISP, if I can't find a way around this.

Sorry you feel that way.

Quote from: djh

Quote Without the spam filtering in place, you'd find our servers would end up on blacklists pretty frequently. When this happens it prevents every customer we have from sending email to domains that's using said blacklists. I appreciate your problem, but you need to find a better solution, IMHO.

We've tried a multitude of solutions over the years and compared to others Cloudmark does a good job. As I've mentioned above though, no solution is perfect. What I struggle to understand is exactly why this seems to cause you so many problems? The majority of people would never even encounter the issue, let alone encounter it repeatedly. Perhaps the activity of one of the domains you send to causes it to repeatedly end up on Cloudmarks naughty-boy lists?

[#5]

A couple of things that are not quite clear:

Quote from: djh

Now I'm not sending spam, I'm sending messages I've written.

Those are not mutually exclusive, someone has to write spam

Quote from: djh

commercially relevant mail.

So, does that imply bulk mailings from your business account?

[#6]

Quote from: PeeGee

A couple of things that are not quite clear: Quote from: djh Now I'm not sending spam, I'm sending messages I've written. Those are not mutually exclusive, someone has to write spam Quote from: djh commercially relevant mail. So, does that imply bulk mailings from your business account?

Thanks for thinking about the problem but if you can't think of anything constructive to say, <removed> somewhere else please.
jim:red Removed abbreviation is against this Forum Rule mod:end

[#7]

Quote from: Bob

Quote Please note that all the other email systems I use do behave in that way. They send me an email telling me there is a problem. It's only your service that behaves this way, in my experience. Now I'm even more confused. The message will be refused and an 5xx SMTP response presented. There's nothing unusual about this and it's compliant with RFC's. I was under the impression all decent mail clients would return this SMTP rejection at the point of sending?

Then you classify Evolution as indecent, because it doesn't, I'm afraid.  Only if the message is sent as it is started up. I agree that Evo could be improved, but that's not the subject. And as I pointed out, I don't have this problem anywhere else because all the other mailing systems I deal with do send me a rejection message.

Quote

As above, we don't silently discard anything. Our server returns an explicit 5xx response. I'm sure you can understand that it's simply not feasible to have suspect messages checked by a human being

As far as I'm concerned, what you're doing is a very close equivalent to the silent calls that Talk-Talk just got fined for. You're causing me grief because you're not prepared to spend money to improve your systems.
And yes, given the amount of hassle this causes me and I in turn cause for you, I'd think it would be entirely feasible to have a human check any occurence of a suspect message from my account. Figure out why you're getting false positives and change your system so you don't.

Quote

We've tried a multitude of solutions over the years and compared to others Cloudmark does a good job. As I've mentioned above though, no solution is perfect. What I struggle to understand is exactly why this seems to cause you so many problems? The majority of people would never even encounter the issue, let alone encounter it repeatedly. Perhaps the activity of one of the domains you send to causes it to repeatedly end up on Cloudmarks naughty-boy lists?

I have no idea about the recipient's email systems, but that should be a problem for them to deal with, not me. As far as I am concerned, they are simply a company I want to buy something from.
Let's assume the worst case - that the company I'm trying to send to has completely incompetent admins and their servers are spewing out huge amounts of spam. The fundamental point is that sending mail to an address that is a source of spam, even when that email includes URLs in that domain (because it is a reply to one of their mails) is NOT spam. Whatever fingerprint you are using needs to include some actual payload, not just URLs. And it needs to care about the direction of the email. Mail that matches a spam signature coming FROM that spam source is spam; mail that matches the spam signature of the source that is sent TO the source is NOT spam.

[#8]

Quote from: djh

Quote from: Bob Quote Please note that all the other email systems I use do behave in that way. They send me an email telling me there is a problem. It's only your service that behaves this way, in my experience. Now I'm even more confused. The message will be refused and an 5xx SMTP response presented. There's nothing unusual about this and it's compliant with RFC's. I was under the impression all decent mail clients would return this SMTP rejection at the point of sending? Then you classify Evolution as indecent, because it doesn't, I'm afraid.

In which case I reserve my right to remain confused because Evolution does return an error when I try. Perhaps your problem isn't being caused by what I think it is?

Quote from: djh

Quote As above, we don't silently discard anything. Our server returns an explicit 5xx response. I'm sure you can understand that it's simply not feasible to have suspect messages checked by a human being As far as I'm concerned, what you're doing is a very close equivalent to the silent calls that Talk-Talk just got fined for. You're causing me grief because you're not prepared to spend money to improve your systems.

It's a million miles apart from the Talk Talk situation and we're not going to get fined for doing something that is RFC-compliant (although based on the above, perhaps it isn't 5xx SMTP rejections that are causing you grief).

Quote from: djh

And yes, given the amount of hassle this causes me and I in turn cause for you, I'd think it would be entirely feasible to have a human check any occurence of a suspect message from my account. Figure out why you're getting false positives and change your system so you don't.

If raising a support ticket is too much hassle then there may be another way (it depends on whether or not it is these 5xx rejections that are causing your problem). What happens if you try sending/forwarding one of these problematic emails using our Webmail platform? It should return the rejection message containing the spam fingerprint string. If it does then the message will end up in the Drafts folder. This can then be moved to the Spam folder where you can highlight it and click the 'This message is not spam' button. That sends the message to Cloudmark as a false positive. Whilst the results won't be immediate, with a few messages this will probably reset the trigger. A human trawling our server logs for the 5xx rejections would be futile because we can't see the content of the email at this stage (because it was never accepted) and therefore would have no idea whether it was genuine or not.
Whilst it sounds like you'd rather move ISP, it's easy enough to get access to a third party SMTP service for ~£1/mnth. There's always the possibility that you'd encounter problems there though too if your messages fall foul of our spam filters so frequently.

Quote from: djh

Quote We've tried a multitude of solutions over the years and compared to others Cloudmark does a good job. As I've mentioned above though, no solution is perfect. What I struggle to understand is exactly why this seems to cause you so many problems? The majority of people would never even encounter the issue, let alone encounter it repeatedly. Perhaps the activity of one of the domains you send to causes it to repeatedly end up on Cloudmarks naughty-boy lists? I have no idea about the recipient's email systems, but that should be a problem for them to deal with, not me. As far as I am concerned, they are simply a company I want to buy something from. Let's assume the worst case - that the company I'm trying to send to has completely incompetent admins and their servers are spewing out huge amounts of spam. The fundamental point is that sending mail to an address that is a source of spam, even when that email includes URLs in that domain (because it is a reply to one of their mails) is NOT spam. Whatever fingerprint you are using needs to include some actual payload, not just URLs. And it needs to care about the direction of the email. Mail that matches a spam signature coming FROM that spam source is spam; mail that matches the spam signature of the source that is sent TO the source is NOT spam.

A lot of spammers use compromised email accounts to send messages. We know this because we see it all the time where customers respond to phishing emails that allow a spammer into our webmail systems to sent unsolicited email. All of this would be missed if the spam filtering was not applied to outbound traffic.
We've invested a lot of time and money into our mail platform over the years and the current solution is not going to undergo any significant change any time soon. Perhaps you can elaborate on your problem though because I no longer think we're talking about the same thing? You experience with Evolution certainly doesn't mirror mine.
I'm wondering now what /volume/ of messages you send? It could be that you're hitting the rate limits that are applied (and can be adjusted by us in certain scenarios). When that happens the server would return a temporary 4xx error that Evolution might not handle as gracefully.