Ok to (hopefully) clear this up once and for all .....
Re differences between internal/external systems: Finally, the answer that I (and no doubt a few others) just knew was going to get teased out eventually. The PN internal system and the customer facing system are/were indeed different animals. Thank you.
Can I therefore suggest that ALL of us bear the following in mind whenever considering possible problems and particularly so when trying to reproduce said problems.
Messages that are routed:
source -> postini system 200 -> plusnet -> username1/mailbox
are likely to be handled/analysed differently to messages routed:
source -> postini system 5 -> plusnet -> username2/mailbox
Also, a message that has been sent with the following routing:
source -> postini -> plusnet -> username1/mailbox
... is likely to be handled/analysed similarly to messages routed:
source -> postini -> plusnet -> username2/mailbox
... is likely to handled/analysed slightly differently to messages routed:
source -> plusnet -> postini -> plusnet -> username1/mailbox
... is likely to be handled/analysed quite differently to messages routed:
source -> mailserver -> plusnet -> postini -> plusnet -> username1/mailbox
I would suggest that the more servers that the message passes through prior to getting to postini then the more likely it is that the message will be handled/analysed differently and the greater that difference will be.
In addition, due to the dynamic nature of the postini system(s), even two identical messages sent via identical routes on one particular postini system are likely to be handled/analysed differently unless they were sent within a relatively short time frame.
I'm not in any way suggesting that these are 100% hard facts and that differences are always very significant but it is certainly what appears to be indicated from my various tests and other circumstantial evidence. There are so many variables here that getting much the same result twice isn't that common to say the least and different routing compounds this greatly.
Re x-pstn-2strike I'm still not sure that what you (and Bob) have said covers what is happening so let me state again what I think the situation is and you can confirm/deny it as appropriate. Again, without inside knowledge, because of the time it takes to mess around and not to mention the danger of getting blacklisted if you try too hard, it is difficult to establish 100% hard facts but my various tests and other circumstantial evidence indicate the following:
"x-pstn-2strike: clear" is the indicator for a mechanism that allows a message that has been considered as pretty obvious spam by postini to be delivered to the customer because it has come from a source not previously known for sending spam. The source is not currently blocked, has no long-term history or indeed anything else to indicate that it is a common source of spam messages but the routing, subject or content in general leads postini to conclude that it really is 100% spam. As the name would suggest, it means "two strikes and you're out" so you can only get away with it once in an undefined time frame. The "lock out" period appears to be several hours and possibly a day or more.
The existence of the header in a received message indicates that postini consider this message as pretty obvious spam but they have rather reluctantly delivered it to you on this particular occasion.
Any further messages from the same sender/IP within the "lock out" period that are also considered as pretty obvious spam by postini or have been given low scores will be refused and will never be delivered to the customer.
As I've said before, if a sender attempts to send you 6 messages over a period of a few hours and the messages are such that postini considers they are rather obvious spam then only the very first message will be delivered to you. The remaining 5 will be refused by postini and the sender will either get a #571 when trying to send each message or will subsequently receive a non-delivery advice after sending each messages. It doesn't matter if the messages are identical or different, all that matters is that postini consider them to be spam for one reason or another.
Messages that are often false positives on a good day and generally achieve particularly low spam scores are prime candidates for getting this treatment at some time or other. Therefore mailing lists or forums and suchlike that can send out several genuine messages a day are prone to having messages rejected not only because postini routinely and incorrectly scores them low enough to be considered as spam but because sometimes they also classify them as rather obvious spam for one reason or another as well. However, messages can still be considered by postini to be rather obvious spam even though the spam score does not necessarily indicate this. The previously mentioned Odeon Cinemas message(s) fall into this category. The spam score was actually 1.94 but it was still considered as rather obvious spam by postini so got the 2strike header. This means that any following messages with low(ish) spam scores received within the 'lock out' period would have been (and I believe actually were) refused.
One other interesting thought is whether this mechanism works on a per destination address basis or across the board. If it works across the board then any one customer getting a message with x-pstn-2strike: clear from one particular sender/IP is likely to result in other messages from the same sender/IP to other customers all getting refused. I would hope it doesn't work like that though. Maybe I'll add it to my things-to-try-later list and see exactly what does happen.
Also, because of the now confirmed differences between the PN internal and customer facing postini systems, x-pstn-2strike: [number] will not be seen in any messages received by customers. This also means that the PN header "x-pn-pstn: spam 1" has not and will not ever be seen by customers either. However, this situation could possibly change in the future because this functionality may be added/restored to the customer facing postini system at some point in the future. I still rather suspect that this fuctionality has been superseded by something else - xfilter ?
false positives: It can be no surprise to anyone that spammers try to fool filters and make their junk look like forum notifications or whatever. That's the way the game works and that's why I believe it's a long-term losing battle that can ultimately only result in e-mail becoming so totally unreliable that it's completely unusable. All you're really telling me is what I already know - filtering isn't a long-term solution to the problem it can only ever be a temporary fix with a limited life span. The only way to truly resolve the problem is to tackle it at source not try to hide it at destination but that necessitates cooperation between ISPs various together with the will to act responsibly and fix the problem once and for all. Needless to say it's almost certainly never going to happen !
But the fact that forum notifications (or whatever) 'look' like spam is not a good excuse for marking them as such. What it actually means in reality is that Mr.Spammer is doing a far better job than Mr.Postini. I think it also perhaps indicates one of if not 'the' fundamental flaw in these systems. postini and various others actively search for spam with a view to deleting/rejecting or marking as many messages as possible. They consider that the 'best' indicator of their performance is the number of messages deleted/rejected and marked. Well, no surprise there I hear you say ! But the problem IMHO is that is doing only half the job. What is equally if not far more important is to actively search for and deliver genuine messages.
To say that a forum notification (or whatever) just so happens to match the signature for some flavour of spam so gets dealt with accordingly is utter nonsense and a total cop-out. Where is the test for whether it is a genuine message or not ? If you compare the genuine and spam messages there absolutely WILL be indicators that the genuine message is indeed totally genuine. It's not just a case of testing for spam the system should also have an effective test for genuine messages. Maybe it has, I don't know, but the one thing I do know is that if it does then it clearly doesn't work !
I guess that means that the recent batch of spams that look very much like non-delivery advices (they aren't, they just kinda look rather like one) are going to result in genuine NDA's getting dumped sometime soon then.
And what about what appears to be Mr.Spammer's latest tactics of sending spam containing a link to a google search list to bring up their sites rather than adding a direct link to them ? Actually I find that really funny TBH. Using the same organisation to promote their dodgy sites as is also used by many to try and stop spam is simply brilliant ! So, are postini going to consider all messages containing a google search link as spam in future then ? hehehehee. Sorry, I know it's sad and I know it's going to lead to more stupid problems, false positives and lots of unnecessary hassle for everyone but I still find it really amusing.
Re unanswered questions etc. There are several all over the place although recent ones such as regarding differences between internal/external systems now appear to have been addressed at last. There are still relevant others though I suspect but I'm not going to go search now but there certainly is one of major importance that I'll mention in a bit. However my comment was actually in relation to a response Bob made which implied that the 2strike action had been sneakily changed from what I was seeing earlier. I think now that this may have been a misunderstanding from you've said since then but either way, I've detailed again how it appears to work above so someone can confirm or deny this as appropriate.
Apart from earlier queries concerning 2strike,
This Post contains some interesting points particularly now that we have confirmation that internal and customer facing postini systems are different. It relates to configuration management and the possibility of postini making changes in the future that somehow break the PN implementation. Some typical recent examples illustrating the kind of problems that could arise in the future: the total confusion that has existed concerning how 2strike works, configuration errors resulting in dumping rather than rejecting messages and the fact that the PN SPAM 1 header cannot possibly exist because it relies on something that is not actually implemented in the current version of the postini system.
Postini Email Security Trial