Re: spamer spoofing SA headers
>... >Paul, the procmail script Loren and I use simply strips it out. I've read >too many folks on this list talk about scanning outbound for one reason >or another to figure premarking is a good spam sign. > >Of course, there are odd cases to consider. > >Suppose somebody honest or at least passing honest scans outbound, >marks the messages, but sends them anyway premarked as spam. I am >inclined to be a little obnoxious and believe it. If it marks the >message as non-spam I'd strip the markup that *I* might mis-sort >upon, In either case I'd rescan it my self. If either case resulted >in a spam markup, either from me or the sender, it becomes spam. In >fact I'd put in a rule looking for an X-Spam sort of header and >explicitly give a "yes" a healthy big score so that I am sure to believe >the joker who sent it. >... I think, I'm agreeing with both you and Matt. It is not that I'm refusing mail with markup, only emails which are marked to positively be spam. Similarly, I don't care about any existing markup that doesn't indicate spam (or a virus, etc. - since I see a much higher percentage of viruses claim to have been 'Virus-Scan"'d or something similar). All I'm refusing is those sites/emails that are already marked (e.g. with a header "X-Spam-Status: yes" or similar). I think I'm saying that an existing spam status line is much like SPF, the case you'd like is unreliable, but the other case is plenty reliable (e.g. SPF failure on a relayed message is one of the other header checks I'm willing to believe - If you tell me it already failed - not just "softfail"'d, I'll refuse it). Now I am pretty sure that my BAYES believes any existing markup is spammy, but that is probably because more forged markup messages have passed through my servers than valid ones. The cases I see getting refused are mainly those from honest sites who are marking spam as spam, but attempting to deliver it anyway (a valid policy for some sites); This was something I started doing after getting quite a few spams from colleges and universities which were already marked as spam (and yes, they were all getting "caught" by my local SA, but why even accept them when the MTA can do a "cheap" reject?). Paul Shupak [EMAIL PROTECTED]
missing markup (was: Re: spamer spoofing SA headers)
On 12/28/2005 1:13 AM, jdow wrote: (So far nobody has nailed down the PerMsgStatus problems that result in logs that say a message is spam but no markups at all appear on the message. THIS is why I strip off spam markups. I trigger on their presence to indicate that I properly completed a spamc/spamd run. If the header is missing I feed it through spamassassin itself as a backup. The forgery aspect is a pleasant side effect of stripping the headers.) Bug number? Only with spam? The only case of this I've seen is when spamc times out before spamd returns the message. Which of course is the as designed outcome. What sort of processing time are you seeing logged and what's your spamc timeout? Daryl
Re: spamer spoofing SA headers
From: "List Mail User" <[EMAIL PROTECTED]>
>...
>You can only safely skip messages with an X-Spam-Status: that reads
"yes",
>due to the fact that you can't trust it. Of course, spammers can always
>forge a X-Spam-Status: on themselves that declares the message to be
spam,
>but if they do.. more power to em..
>
Or even better, you can check for already marked positive spam
headers and refuse the email on that basis (for like some sites who scan
outgoing mail, but pass mail marked as spam on anyway e.g. ufl.edu is
"big"
on this).
Note that this only works on 3.0++. On 2.6x (and I assume previously) the
SA headers on an incoming mail were stripped before the rules had a chance
to look at the text.
Loren
Not if the mail is never accepted. I reject mail marked that
way with a "550 Already marked as spam" from Postfix (using header
rules - so a quoted mail message won't trigger it). There are plenty
of large institutions and sites "kind enough" to mark outgoing mail
as spam, but send it to you anyway (mostly government or educational
sites).
Paul, the procmail script Loren and I use simply strips it out. I've read
too many folks on this list talk about scanning outbound for one reason
or another to figure premarking is a good spam sign.
Of course, there are odd cases to consider.
Suppose somebody honest or at least passing honest scans outbound,
marks the messages, but sends them anyway premarked as spam. I am
inclined to be a little obnoxious and believe it. If it marks the
message as non-spam I'd strip the markup that *I* might mis-sort
upon, In either case I'd rescan it my self. If either case resulted
in a spam markup, either from me or the sender, it becomes spam. In
fact I'd put in a rule looking for an X-Spam sort of header and
explicitly give a "yes" a healthy big score so that I am sure to believe
the joker who sent it.
This way if a spammer tries to spoof I don't much care if the spam
markup came from J-Random-Machine. The score I'd work with would be
the one tagged with MY machine name. I note spam markups are so
marked these days. (Tagging the spam with a very private machine ID
that is a GUID would be even better. Then stripping the spam headers
would not be necessary, for this purpose.)
(So far nobody has nailed down the PerMsgStatus problems that result
in logs that say a message is spam but no markups at all appear on the
message. THIS is why I strip off spam markups. I trigger on their
presence to indicate that I properly completed a spamc/spamd run. If
the header is missing I feed it through spamassassin itself as a backup.
The forgery aspect is a pleasant side effect of stripping the headers.)
{^_^}
Re: spamer spoofing SA headers
>... >> >You can only safely skip messages with an X-Spam-Status: that reads >"yes", >> >due to the fact that you can't trust it. Of course, spammers can always >> >forge a X-Spam-Status: on themselves that declares the message to be >spam, >> >but if they do.. more power to em.. >> > >> >> Or even better, you can check for already marked positive spam >> headers and refuse the email on that basis (for like some sites who scan >> outgoing mail, but pass mail marked as spam on anyway e.g. ufl.edu is >"big" >> on this). > >Note that this only works on 3.0++. On 2.6x (and I assume previously) the >SA headers on an incoming mail were stripped before the rules had a chance >to look at the text. > >Loren > Not if the mail is never accepted. I reject mail marked that way with a "550 Already marked as spam" from Postfix (using header rules - so a quoted mail message won't trigger it). There are plenty of large institutions and sites "kind enough" to mark outgoing mail as spam, but send it to you anyway (mostly government or educational sites). Paul Shupak [EMAIL PROTECTED]
Re: spamer spoofing SA headers
--- Begin Message --- Thanks for the help. I am useing CommuniGate ,clamav, and scanspam.sh to call spamc/spamd, in the rules I am checking for the SA header to prevent looping the message in the queue. Never thought that this would happen. If I read the docs right I can create a custom header message that I can have SA add to my messages to prevent message looping, right? Jonn On Tue, 27 Dec 2005 15:10:39 -0500 Matt Kettler <[EMAIL PROTECTED]> wrote: Pollywog wrote: On 12/27/2005 02:56 pm, Matt Kettler wrote: At 08:48 AM 12/27/2005, Jonn R Taylor wrote: How can I make this go thourgh SA when it thinks it allready has Why wouldn't it go through SA? SA doesn't have any built-in behaviors that will prevent it from re-scanning a message. I had a similar problem with clamassassin headers, so I had Postfix remove them so that my Maildrop filters would not be confused. I just set the clamassassin headers to IGNORE in Postfix's header_checks, IIRC. Could something like this be done for Spamassassin's headers, by the MTA and would it solve the problem? Why bother? SA isn't confused by them. No sane spamassassin setup would ever have this problem. Period. The problem lies in a user intentionally trying to bypass SA for already scanned mail. The fix lies in not doing something so foolish in the first place. Fix the problem in the implementation, don't cover it up by modifying the input data to hide the existence of this problem. --- End Message ---
Re: spamer spoofing SA headers
> >You can only safely skip messages with an X-Spam-Status: that reads "yes", > >due to the fact that you can't trust it. Of course, spammers can always > >forge a X-Spam-Status: on themselves that declares the message to be spam, > >but if they do.. more power to em.. > > > > Or even better, you can check for already marked positive spam > headers and refuse the email on that basis (for like some sites who scan > outgoing mail, but pass mail marked as spam on anyway e.g. ufl.edu is "big" > on this). Note that this only works on 3.0++. On 2.6x (and I assume previously) the SA headers on an incoming mail were stripped before the rules had a chance to look at the text. Loren
Re: spamer spoofing SA headers
On 12/27/2005 08:10 pm, Matt Kettler wrote: > Why bother? SA isn't confused by them. No sane spamassassin setup would > ever have this problem. Period. > > The problem lies in a user intentionally trying to bypass SA for already > scanned mail. The fix lies in not doing something so foolish in the first > place. Oh okay, I misunderstood and thought it was a problem caused by what the spammer had done, though I don't recall ever having the problem myself. 8)
Re: spamer spoofing SA headers
Pollywog wrote: > On 12/27/2005 02:56 pm, Matt Kettler wrote: > >>At 08:48 AM 12/27/2005, Jonn R Taylor wrote: >> >>>How can I make this go thourgh SA when it thinks it allready has >> >>Why wouldn't it go through SA? >> >>SA doesn't have any built-in behaviors that will prevent it from >>re-scanning a message. > > > I had a similar problem with clamassassin headers, so I had Postfix remove > them so that my Maildrop filters would not be confused. I just set the > clamassassin headers to IGNORE in Postfix's header_checks, IIRC. > > Could something like this be done for Spamassassin's headers, by the MTA and > would it solve the problem? Why bother? SA isn't confused by them. No sane spamassassin setup would ever have this problem. Period. The problem lies in a user intentionally trying to bypass SA for already scanned mail. The fix lies in not doing something so foolish in the first place. Fix the problem in the implementation, don't cover it up by modifying the input data to hide the existence of this problem.
Re: spamer spoofing SA headers
On 12/27/2005 02:56 pm, Matt Kettler wrote: > At 08:48 AM 12/27/2005, Jonn R Taylor wrote: > >How can I make this go thourgh SA when it thinks it allready has > > Why wouldn't it go through SA? > > SA doesn't have any built-in behaviors that will prevent it from > re-scanning a message. I had a similar problem with clamassassin headers, so I had Postfix remove them so that my Maildrop filters would not be confused. I just set the clamassassin headers to IGNORE in Postfix's header_checks, IIRC. Could something like this be done for Spamassassin's headers, by the MTA and would it solve the problem? 8)
Re: spamer spoofing SA headers
>At 08:48 AM 12/27/2005, Jonn R Taylor wrote: >>How can I make this go thourgh SA when it thinks it allready has > >Why wouldn't it go through SA? > >SA doesn't have any built-in behaviors that will prevent it from >re-scanning a message. > >Did you do something in your procmailrc to cause procmail to skip SA if an >X-Spam-Status header exists? > >This is generally a bad idea. >Anyone can forge a SA header, but in this case it's more likely the message >went through a real version of SA on the sender's side. However, the >sender's own SA is likely configured to consider his/her own mail as not spam. > >You can only safely skip messages with an X-Spam-Status: that reads "yes", >due to the fact that you can't trust it. Of course, spammers can always >forge a X-Spam-Status: on themselves that declares the message to be spam, >but if they do.. more power to em.. > Or even better, you can check for already marked positive spam headers and refuse the email on that basis (for like some sites who scan outgoing mail, but pass mail marked as spam on anyway e.g. ufl.edu is "big" on this). Paul Shupak [EMAIL PROTECTED]
Re: spamer spoofing SA headers
At 08:48 AM 12/27/2005, Jonn R Taylor wrote: How can I make this go thourgh SA when it thinks it allready has Why wouldn't it go through SA? SA doesn't have any built-in behaviors that will prevent it from re-scanning a message. Did you do something in your procmailrc to cause procmail to skip SA if an X-Spam-Status header exists? This is generally a bad idea. Anyone can forge a SA header, but in this case it's more likely the message went through a real version of SA on the sender's side. However, the sender's own SA is likely configured to consider his/her own mail as not spam. You can only safely skip messages with an X-Spam-Status: that reads "yes", due to the fact that you can't trust it. Of course, spammers can always forge a X-Spam-Status: on themselves that declares the message to be spam, but if they do.. more power to em..
