Re: Well, it ws nice of them to tell me!
Loren Wilton wrote: So it doesn't happen that often. I did try writing an SA header rule for these first, but it appears that SA strips out 'X-Spam-Flag' headers out before the rules are run. SA Strips out X-Spam-* on the assumption that it previously added them. Previous to 3.0 it did this before the rules ran on the text. Now I think you can still get to them with full rules, but I think they are still stripped from normal header rules. If you have something like procmail in the chain before SA you can change incoming X-Spam-* to something like X-PreviousSpam-* and end up with them present to scan. and if using postfix, a header_checks like this: /^(X-Spam-.*)/ REPLACE X-$1 will rename them to X-X-Spam-* which can then be used in SA rules (or other rules).
Re: Well, it ws nice of them to tell me!
Loren Wilton wrote: X-SpamFilter-By: BOX Solutions SpamTrap 1.1 with qID lBDNlb6m031347, This message is to be blocked by code: bkndr63272 Subject: [Spam-Mail] We invite you to join us as a Silver PowerSeller! (This message should be blocked: bkndr63272) Shame they didn't just block it so I woudln't have to! Hehe - I've seen this happen before - e.g. messages from AOL and others with 'X-Spam-Flag: YES' in the headers, but not in this particular format. I now block these at SMTP time: 214-2.0.0 age=54139 (00 15:02:19) 214-2.0.0 004 CLIENTS=341510 (100.00%) 214-2.0.0 110 spamd-sender-marked-spam=16 (0.04%) So it doesn't happen that often. I did try writing an SA header rule for these first, but it appears that SA strips out 'X-Spam-Flag' headers out before the rules are run. Cheers, Steve.
Re: Well, it ws nice of them to tell me!
On Fri, 14 Dec 2007 12:12:27 + Steve Freegard [EMAIL PROTECTED] wrote: Loren Wilton wrote: X-SpamFilter-By: BOX Solutions SpamTrap 1.1 with qID lBDNlb6m031347, This message is to be blocked by code: bkndr63272 Subject: [Spam-Mail] We invite you to join us as a Silver PowerSeller! (This message should be blocked: bkndr63272) Shame they didn't just block it so I woudln't have to! Hehe - I've seen this happen before - e.g. messages from AOL and others with 'X-Spam-Flag: YES' in the headers, but not in this particular format. I now block these at SMTP time: 214-2.0.0 age=54139 (00 15:02:19) 214-2.0.0 004 CLIENTS=341510 (100.00%) 214-2.0.0 110 spamd-sender-marked-spam=16 (0.04%) So it doesn't happen that often. I did try writing an SA header rule for these first, but it appears that SA strips out 'X-Spam-Flag' headers out before the rules are run. I believe SA strips all headers that start with 'X-Spam-'. -- _|_ (_| |
RE: Well, it ws nice of them to tell me!
-Original Message- From: Giampaolo Tomassoni [mailto:[EMAIL PROTECTED] Sent: Friday, December 14, 2007 2:26 PM To: users@spamassassin.apache.org Subject: RE: Not sure why DOS_OE_TO_MX fired -Original Message- From: Andrew Hearn [mailto:[EMAIL PROTECTED] Sent: Friday, December 14, 2007 1:27 PM To: users@spamassassin.apache.org Subject: Not sure why DOS_OE_TO_MX fired Hello, I'm not sure why DOS_OE_TO_MX fired on this message, as the headers say it was delivered to b.painless.aaisp.net.uk which relayed it on to z.hopeless.aaisp.net.uk. b.painless isn't the MX for the domain... Any ideas? -Thanks! I bet 2001:8b0:0:81::51bb:5134 or 217.169.3.9 is in your internal_networks, right? If this is the case, the header rule __DOS_SINGLE_EXT_RELAY fires on this message, since it only looks to external relays. My suggestion is to put both 2001:8b0:0:81::51bb:5134 AND 217.169.3.9 into your internal network, or you may put 2001:8b0:0:81::51bb:5134 in the trusted network and 217.169.3.9 in your internal. However, you should obtain either none or both the servers in your external network. This means you are going not to check you outgoing messages against some URIBL services, but anyway it is quite silly to check them if you are the provider: that way, your may risk to block yourself all the outgoing traffic... Sorry, I was imprecise and wrong here. If you put both nets in your internal_network (or in your trusted_network), then you will skip any DNSBL (not URIBL) checks on these hosts. However, the fact it is risky for a ISP to not put internal/trust them still holds. Giampaolo Giampaolo Return-path: [EMAIL PROTECTED] Envelope-to: [EMAIL PROTECTED] Delivery-date: Fri, 14 Dec 2007 11:45:39 + Received: from [2001:8b0:0:81::51bb:5134] (helo=b.painless.aaisp.net.uk) by z.hopeless.aaisp.net.uk with esmtp (Exim 4.63) (envelope-from [EMAIL PROTECTED]) id 1J38z2-0004B8-FV for [EMAIL PROTECTED]; Fri, 14 Dec 2007 11:45:39 + Received: from [217.169.3.9] (helo=DFTJ542J) by b.painless.aaisp.net.uk with smtp (Exim 4.62) (envelope-from [EMAIL PROTECTED]) id 1J38z2-00036f-7g for [EMAIL PROTECTED]; Fri, 14 Dec 2007 11:45:36 + Message-ID: [EMAIL PROTECTED] From: Fiona Murphy [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: website emergency! Date: Fri, 14 Dec 2007 11:45:33 - MIME-Version: 1.0 Content-Type: multipart/alternative; boundary==_NextPart_000_00AF_01C83E46.D5CB6A50 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Virus-Scanned: Clear (Version: ClamAV 0.91.2/5116/Fri Dec 14 07:14:39 2007, by smtp.aaisp.net.uk) X-AA-SMTP-Time-Scanned:YES X-Spam-Score: 4.0 X-AASpam-Report: Spam detection software, running on the system b.spamless.aaisp.net.uk, has processed this message. This message scored (4.0 points and 4.6 are required to mark as spam) pts rule name description -- -- 1.2 HTML_MESSAGE BODY: HTML included in message 0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60% [score: 0.5071] 0.0 NO_VIRUS_FOUND There were no viruses found in this message by ClamAV 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers
Re: Well, it ws nice of them to tell me!
So it doesn't happen that often. I did try writing an SA header rule for these first, but it appears that SA strips out 'X-Spam-Flag' headers out before the rules are run. SA Strips out X-Spam-* on the assumption that it previously added them. Previous to 3.0 it did this before the rules ran on the text. Now I think you can still get to them with full rules, but I think they are still stripped from normal header rules. If you have something like procmail in the chain before SA you can change incoming X-Spam-* to something like X-PreviousSpam-* and end up with them present to scan. Loren
Re: Well, it ws nice of them to tell me!
On Friday 14 December 2007 10:30 am, Loren Wilton wrote: So it doesn't happen that often. I did try writing an SA header rule for these first, but it appears that SA strips out 'X-Spam-Flag' headers out before the rules are run. SA Strips out X-Spam-* on the assumption that it previously added them. Previous to 3.0 it did this before the rules ran on the text. Now I think you can still get to them with full rules, but I think they are still stripped from normal header rules. If you have something like procmail in the chain before SA you can change incoming X-Spam-* to something like X-PreviousSpam-* and end up with them present to scan. Loren I use a simple formail recipe in my .procmailrc which takes the X-Spam* headers from my domains mail which is hosted elsewhere and changes it to: Old-X-Spam-Status: Yes, score=9.5 Old-X-Spam-Score: 95 Old-X-Spam-Bar: + Old-X-Spam-Report: Spam detection software, running on the system The recipe is: :0Wfh *^To:[EMAIL PROTECTED] | formail -i X-Spam Tp -i headerfield Same as -A, except that any existing similar fields are renamed by prepending an ``Old-'' prefix. If headerfield consists only of a field-name, it will not be appended. Don't know if this is what you're looking for or not. -- Chris KeyID 0xE372A7DA98E6705C 21:45:34 up 89 days, 1:34, 1 user, load average: 0.48, 0.24, 0.13 pgpkgqcsHlkSe.pgp Description: PGP signature
Well, it ws nice of them to tell me!
X-SpamFilter-By: BOX Solutions SpamTrap 1.1 with qID lBDNlb6m031347, This message is to be blocked by code: bkndr63272 Subject: [Spam-Mail] We invite you to join us as a Silver PowerSeller! (This message should be blocked: bkndr63272) Shame they didn't just block it so I woudln't have to! Loren
