Postini Email Security Trial
Quote from: Bob I can't remember exactly what the error is when Postini see's something as spam but it's another 5xx error that's more indicative of the problem
I hate to tell you this but my tests so far indicate that spam is being dumped/blackholed rather than rejected
I can think of reasons why some of my recent tests may have resulted in this action but it's not good in general and I can see it causing problems for some customers. Any customer who could expect to receive 'support' type emails (primarily business customers but also private customers who draw the short straw for resolving other peoples problems !) along the lines of "What can I do to stop getting lots of spam like this: ..." will apparently not be getting most of them (if any) and the sender will not be aware the message wasn't delivered. Any significant amount of information cut from a spammy message and pasted or attached to a genuine message appears to result (on most occasions) in that message NOT being delivered and NOT being rejected either despite the fact that it could and should have been.
Maybe it is inevitable that this scenario will be problematic with any spam filter but I don't see any excuse for not rejecting a message considered spammy whenever possible. I do hope mail to the DSPAM report addresses isn't routed via postini because if it is then that could well explain the nose-dive in performance reported recently as spam reports are quite likely being blackholed by postini !
Why are postini apparently dumping rather than rejecting spam ?
Mike - I'd like to know how you are able to check this out.
The support type emails you describe are person to person emails and we've already been told that Plusnet's SLA with Postini is for 100% delivery of those.
The support type emails you describe are person to person emails and we've already been told that Plusnet's SLA with Postini is for 100% delivery of those.
I have limited evidence but evidence all the same to indicate that dumping is most likely happening. I'd like to get more data/evidence to support this but I feel that I need to be more than a bit careful here because my IP and/or A/C could end up blacklisted somewhere if I try too hard !
My reasoning is this: When I send a number of identical (or virtually identical) test messages by various means/routes to my test A/C and the ONLY route that appears to guarantee that the message is received is by sending it via mx-core/last then there are only 2 possible explanations IMHO:
(1) postini are dumping (some but not necessarily all) mail that they consider is spam rather than rejecting it.
(2) postini (or possibly PN) are losing customers mail in general.
I have absolutely no evidence so far to suggest that (2) is likely to be the case, therefore as some messages were not received and I did not receive a formal rejection (e.g. #55x: This message contains spam) either directly or indirectly then I conclude that (1) explains the situation ... unless someone else has an alternative option of course.
Re: SLA type comments in general: The test messages sent could/should have been considered 'person-to-person' as they were sent manually by me from one A/C to me at another A/C individually over a short(ish) period of time rather than en-masse. The fact that I did not receive some suggests that 100% delivery of person-to-person mail may not be being achieved. Similarly, if reports of forum notifications etc. being classified as spam are correct then too many of these false positives suggests that 0.0003% false positives may not be being achieved either.
PS: I'm not talking about dumping to prevent backscatter - i.e preventing a bounce being sent to an innocent party who has had their e-mail address faked in a spammy message. I am talking about messages considered as being spammy not apparently being refused/rejected at MX level.
My reasoning is this: When I send a number of identical (or virtually identical) test messages by various means/routes to my test A/C and the ONLY route that appears to guarantee that the message is received is by sending it via mx-core/last then there are only 2 possible explanations IMHO:
(1) postini are dumping (some but not necessarily all) mail that they consider is spam rather than rejecting it.
(2) postini (or possibly PN) are losing customers mail in general.
I have absolutely no evidence so far to suggest that (2) is likely to be the case, therefore as some messages were not received and I did not receive a formal rejection (e.g. #55x: This message contains spam) either directly or indirectly then I conclude that (1) explains the situation ... unless someone else has an alternative option of course.
Re: SLA type comments in general: The test messages sent could/should have been considered 'person-to-person' as they were sent manually by me from one A/C to me at another A/C individually over a short(ish) period of time rather than en-masse. The fact that I did not receive some suggests that 100% delivery of person-to-person mail may not be being achieved. Similarly, if reports of forum notifications etc. being classified as spam are correct then too many of these false positives suggests that 0.0003% false positives may not be being achieved either.
PS: I'm not talking about dumping to prevent backscatter - i.e preventing a bounce being sent to an innocent party who has had their e-mail address faked in a spammy message. I am talking about messages considered as being spammy not apparently being refused/rejected at MX level.
I've just come across the lowest score ever for a notification email from these forums:
To: abc@xyz.plus.comSo much for the training Phil reckons happened!
Subject: Topic reply: When will Plusnet tell people that they are behind a [proxy]?
From: "Forum" <community@plus.net>
Date: Mon, 24 Dec 2007 21:05:11 -0000
Message-ID: <d2338bbe29d80aa000920f869216d797-m478460@plus.net>
X-Mailer: SMF
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="SMF-29daf64d80a5cd1197fe21a7442c9057"
Content-Transfer-Encoding: 7bit
X-pstn-neptune: 0/0/0.00/0
X-pstn-levels: (S: 0.00078/92.57537 R:95.9108 P:95.9108 M:97.0282 C:98.6951 )
X-pstn-settings: 1 (0.1500:0.1500) gt3 gt2 gt1 r p m c
X-pstn-addresses: from <community@plus.net> [db-null]
X-pn-pstn: Spam 2
X-PN-VirusFiltered: by PlusNet MXCore (v2.00)