You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Per Jessen <pe...@computer.org> on 2009/11/30 15:16:26 UTC

Is there a way of forcing spamd not to process malformed messages? (NO_RELAYS, NO_RECEIVED etc).

I seem to be having more emails with NO_RELAYS than I normally see, and
I'd like to havee spamd just refuse to process them.  That way they'd
get left in the queue, and I'd have something to debug. 


/Per Jessen, Zürich


Re: Is there a way of forcing spamd not to process malformed messages? (NO_RELAYS, NO_RECEIVED etc).

Posted by Per Jessen <pe...@computer.org>.
Per Jessen wrote:

> Matus UHLAR - fantomas wrote:
> 
>> On 30.11.09 16:41, Per Jessen wrote:
>>> I could, but it won't help - rest assured it has the headers.
>>> Anyway, how about a way to make spamd refuse to process a message
>>> when it appears to to have any?
>> 
>> which MTA do you use? How do you plug SA in?
> 
> MTA is postfix,  I call spamd directly using the spamc protocol (but
> not spamc).
> 
>> where do those messages come from?
> 
> For instance a couple from msg.oleane.net, but it varies.
> 

I forgot to add - when the mail is sent through and I later run it
through spamassassin mnaually, everything works fine(!) - so something
happens in spamd or before. That's why I want spamd to refuse
processing such that the message will remain queued in postfix.  


/Per Jessen, Zürich


Re: Is there a way of forcing spamd not to process malformed messages? (NO_RELAYS, NO_RECEIVED etc).

Posted by Per Jessen <pe...@computer.org>.
Matus UHLAR - fantomas wrote:

>> > Seeing the headers from one of these would be helpful, can you post
>> > a sample? Body not needed. What I'm looking for is the presence of
>> > any Received: header not added by _your_ MTA. I would wager that
>> > the problematic messages when examined in your queue will only have
>> > one Received: header.
>> 
>> Here is one example:  http://jessen.ch/files/email77
> 
> I see headers here byt they all seem to be added by
> inbound.spamchek.net which is I guess your machine.

Yup.

> It is message generated by mail2.emirates.net.ae and the generating
> host did not create any Received: header (apparently since it did not
> receive the message - it only created it and sent it to you).

Yep, it's just a DSN.

>> The really weird thing is that when I run that through SA manually
>> with "spamassassin -t -x ", there is no problem.
> 
> It's because at time you scan the message, the headers were already
> added by your MTA.

But that goes for _both_ situations - in spamd and in the manual run. 
The message is first seen by my smtpd#1, the Received: header is added,
and then I call the smtp proxy to run spamd. 


/Per Jessen, Zürich


Re: Is there a way of forcing spamd not to process malformed messages? (NO_RELAYS, NO_RECEIVED etc).

Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
> John Hardin wrote:
> > What's odd here is it sounds like you're describing messages that have
> > been received from a third-party MTA rather than an external MUA, so
> > they _should_ have a Received: header added by that MTA.

On 01.12.09 08:50, Per Jessen wrote:
> Yes, most would be coming from a third-party MTA - except for most of
> the spam :-)

so, is it the spam which you want prevent from checking by SA? :)

> > Seeing the headers from one of these would be helpful, can you post a
> > sample? Body not needed. What I'm looking for is the presence of any
> > Received: header not added by _your_ MTA. I would wager that the
> > problematic messages when examined in your queue will only have one
> > Received: header.
> 
> Here is one example:  http://jessen.ch/files/email77

I see headers here byt they all seem to be added by inbound.spamchek.net
which is I guess your machine.

It is message generated by mail2.emirates.net.ae and the generating host did
not create any Received: header (apparently since it did not receive the
message - it only created it and sent it to you).

> The really weird thing is that when I run that through SA manually
> with "spamassassin -t -x ", there is no problem.

It's because at time you scan the message, the headers were already added by
your MTA.

> That's why I'd like to have something like "score NO_RELAYS die" to make
> spamd quit processing it.

well, you can shortcircuit on NO_RELAYS but I think you should either fake
Received: headeror use a program that does it (like milter)

-- 
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Spam = (S)tupid (P)eople's (A)dvertising (M)ethod

Re: Is there a way of forcing spamd not to process malformed messages? (NO_RELAYS, NO_RECEIVED etc).

Posted by David B Funk <db...@engineering.uiowa.edu>.
On Mon, 30 Nov 2009, Per Jessen wrote:

> John Hardin wrote:
>
> > That proxy shouldn't pass a message to spamd unless it has a Received:
> > header, and I would suggest that it should not pass a message to spamd
> > unless it has a Received header that was added by the local MTA;
>
> A message will always have one of those.  That is what is so
> mind-boggling.
>
> > In the messages that fail in this manner is there only a single
> > Received: header, for the local MTA hop?
>
> Yep.  That's the one I'm absolutely certain must be present.

The sendmail 'milter' interface receives a copy of the raw incoming
message before the MTA adds any headers to it. So if you're using a
'milter' type mechanism to glue SA into your mail system, your milter
will need to explicitly synthesize and add a "Received:" header
to mimic the one that the MTA adds to the main message.

I don't know anything about the postfix smtp proxy that the OP
has so not sure if the above issue is involved in current situation.


-- 
Dave Funk                                  University of Iowa
<dbfunk (at) engineering.uiowa.edu>        College of Engineering
319/335-5751   FAX: 319/384-0549           1256 Seamans Center
Sys_admin/Postmaster/cell_admin            Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{

Re: Is there a way of forcing spamd not to process malformed messages? (NO_RELAYS, NO_RECEIVED etc).

Posted by Per Jessen <pe...@computer.org>.
John Hardin wrote:

>>
>> No, the message is queued first, then passed to spamd.
> 
> In that case I can't understand why there would not be a local
> Received: header.
> 

Yeah ...

>
MISSING_DATE,MISSING_HEADERS,MISSING_MID,MISSING_SUBJECT,NO_HEADERS_MESSAGE,NO_RECEIVED,NO_RELAYS
> 
> Wow.
> 
> I would suggest you look closely at your proxy. Are you _positive_
> it's in the mail stream at the point you think it is? Are you
> _positive_ that it will always see a complete message (i.e. headers
> and body)?

Well, I'm beginning to have some doubts now, but it has been working
fine for the last two-three years.  I'll have to double check my code -
maybe there's a weird corner case that's becoming more and more exposed
(for whatever reason).

>> That's why I'd like to have something like "score NO_RELAYS die" to
>> make spamd quit processing it.
> 
> That's probably not going to happen. The scan/no-scan decision has to
> be made upstream.

It was just a thought - although it doesn't really sound like a
scan/noscan decision. I mean, the message has already been scanned, but
it has a condition that - according to my rules - makes it an invalid
scan/message.  I'm looking through the code to see if I can the right
place. 


/Per Jessen, Zürich


Re: Is there a way of forcing spamd not to process malformed messages? (NO_RELAYS, NO_RECEIVED etc).

Posted by John Hardin <jh...@impsec.org>.
On Tue, 1 Dec 2009, Per Jessen wrote:

> John Hardin wrote:
>
>> On Mon, 30 Nov 2009, Per Jessen wrote:
>>
>>> John Hardin wrote:
>>>
>>>> That proxy shouldn't pass a message to spamd unless it has a
>>>> Received: header, and I would suggest that it should not pass a
>>>> message to spamd unless it has a Received header that was added by
>>>> the local MTA;
>>>
>>> A message will always have one of those.  That is what is so
>>> mind-boggling.
>>
>> No, there are circumstances when it won't.  The MUA generally does not
>> add a Received: header when it composes the message headers for a new
>> message, it's up to the MTAs to do that. So the message sent from the
>> MUA to the first MTA will likely not have a Received: header (modulo
>> forgery, of course, and things like webmail MUAs).
>
> The MUA will start a conversation with my first smtpd - that will cause
> a Received: header to be added.  The message is then queued, to be
> picked up by the smtp proxy which invokes spamd.  In this situation,
> there will always be at least one Received: header.

Okay, I misunderstood your mail architecture then.

>> What's odd here is it sounds like you're describing messages that have
>> been received from a third-party MTA rather than an external MUA, so
>> they _should_ have a Received: header added by that MTA.
>
> Yes, most would be coming from a third-party MTA - except for most of
> the spam :-)

:)

Well, the spam _pretends_ it comes from an MTA so for the purposes of 
Received: headers we can ignore bots.

>>>> In the messages that fail in this manner is there only a single
>>>> Received: header, for the local MTA hop?
>>>
>>> Yep.  That's the one I'm absolutely certain must be present.
>>
>> Yes, but that one is only present _after_ your local MTA has added it.
>
> Correct.
>
>> If you are intercepting inbound mail prior to your MTA (as it sounds
>> like you're doing with your proxy) then it's very possible you will
>> see messages without any Received: header.
>
> No, the message is queued first, then passed to spamd.

In that case I can't understand why there would not be a local Received: 
header.

>> Seeing the headers from one of these would be helpful, can you post a 
>> sample? Body not needed. What I'm looking for is the presence of any 
>> Received: header not added by _your_ MTA. I would wager that the 
>> problematic messages when examined in your queue will only have one 
>> Received: header.
>
> Here is one example:  http://jessen.ch/files/email77

MISSING_DATE,MISSING_HEADERS,MISSING_MID,MISSING_SUBJECT,NO_HEADERS_MESSAGE,NO_RECEIVED,NO_RELAYS

Wow.

I would suggest you look closely at your proxy. Are you _positive_ it's in 
the mail stream at the point you think it is? Are you _positive_ that it 
will always see a complete message (i.e. headers and body)?

You might want to try adding logging and message capture to your proxy 
while you're troubleshooting this. It looks like somehow it's getting only 
the body of the message for some messages.

> The really weird thing is that when I run that through SA manually
> with "spamassassin -t -x ", there is no problem.

Is that taking the message from the queue of the first real MTA, or the 
second?

> That's why I'd like to have something like "score NO_RELAYS die" to 
> make spamd quit processing it.

That's probably not going to happen. The scan/no-scan decision has to be 
made upstream.

-- 
  John Hardin KA7OHZ                    http://www.impsec.org/~jhardin/
  jhardin@impsec.org    FALaholic #11174     pgpk -a jhardin@impsec.org
  key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
   Individual liberties are always "loopholes" to absolute authority.
-----------------------------------------------------------------------
  14 days until Bill of Rights day

Re: Is there a way of forcing spamd not to process malformed messages? (NO_RELAYS, NO_RECEIVED etc).

Posted by Per Jessen <pe...@computer.org>.
John Hardin wrote:

> On Mon, 30 Nov 2009, Per Jessen wrote:
> 
>> John Hardin wrote:
>>
>>> That proxy shouldn't pass a message to spamd unless it has a
>>> Received: header, and I would suggest that it should not pass a
>>> message to spamd unless it has a Received header that was added by
>>> the local MTA;
>>
>> A message will always have one of those.  That is what is so
>> mind-boggling.
> 
> No, there are circumstances when it won't.  The MUA generally does not 
> add a Received: header when it composes the message headers for a new
> message, it's up to the MTAs to do that. So the message sent from the
> MUA to the first MTA will likely not have a Received: header (modulo
> forgery, of course, and things like webmail MUAs).

The MUA will start a conversation with my first smtpd - that will cause
a Received: header to be added.  The message is then queued, to be
picked up by the smtp proxy which invokes spamd.  In this situation,
there will always be at least one Received: header. 

> What's odd here is it sounds like you're describing messages that have
> been received from a third-party MTA rather than an external MUA, so
> they _should_ have a Received: header added by that MTA.

Yes, most would be coming from a third-party MTA - except for most of
the spam :-)

>>> In the messages that fail in this manner is there only a single
>>> Received: header, for the local MTA hop?
>>
>> Yep.  That's the one I'm absolutely certain must be present.
> 
> Yes, but that one is only present _after_ your local MTA has added it.

Correct.

> If you are intercepting inbound mail prior to your MTA (as it sounds
> like you're doing with your proxy) then it's very possible you will
> see messages without any Received: header.

No, the message is queued first, then passed to spamd.

> Seeing the headers from one of these would be helpful, can you post a
> sample? Body not needed. What I'm looking for is the presence of any
> Received: header not added by _your_ MTA. I would wager that the
> problematic messages when examined in your queue will only have one
> Received: header.

Here is one example:  http://jessen.ch/files/email77

The really weird thing is that when I run that through SA manually
with "spamassassin -t -x ", there is no problem.  That's why I'd like
to have something like "score  NO_RELAYS die" to make spamd quit
processing it. 


/Per Jessen, Zürich


Re: Is there a way of forcing spamd not to process malformed messages? (NO_RELAYS, NO_RECEIVED etc).

Posted by John Hardin <jh...@impsec.org>.
On Mon, 30 Nov 2009, Per Jessen wrote:

> John Hardin wrote:
>
>> That proxy shouldn't pass a message to spamd unless it has a Received: 
>> header, and I would suggest that it should not pass a message to spamd 
>> unless it has a Received header that was added by the local MTA;
>
> A message will always have one of those.  That is what is so 
> mind-boggling.

No, there are circumstances when it won't. The MUA generally does not add 
a Received: header when it composes the message headers for a new message, 
it's up to the MTAs to do that. So the message sent from the MUA to the 
first MTA will likely not have a Received: header (modulo forgery, of 
course, and things like webmail MUAs).

What's odd here is it sounds like you're describing messages that have 
been received from a third-party MTA rather than an external MUA, so they 
_should_ have a Received: header added by that MTA.

>> In the messages that fail in this manner is there only a single
>> Received: header, for the local MTA hop?
>
> Yep.  That's the one I'm absolutely certain must be present.

Yes, but that one is only present _after_ your local MTA has added it. If 
you are intercepting inbound mail prior to your MTA (as it sounds like 
you're doing with your proxy) then it's very possible you will see 
messages without any Received: header.

Seeing the headers from one of these would be helpful, can you post a 
sample? Body not needed. What I'm looking for is the presence of any 
Received: header not added by _your_ MTA. I would wager that the 
problematic messages when examined in your queue will only have one 
Received: header.

-- 
  John Hardin KA7OHZ                    http://www.impsec.org/~jhardin/
  jhardin@impsec.org    FALaholic #11174     pgpk -a jhardin@impsec.org
  key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
   Mine eyes have seen the horror of the voting of the horde;
   They've looted the fromagerie where guv'ment cheese is stored;
   If war's not won before the break they grow so quickly bored;
   Their vote counts as much as yours.                          -- Tam
-----------------------------------------------------------------------
  15 days until Bill of Rights day

Re: Is there a way of forcing spamd not to process malformed messages? (NO_RELAYS, NO_RECEIVED etc).

Posted by Per Jessen <pe...@computer.org>.
John Hardin wrote:

> That proxy shouldn't pass a message to spamd unless it has a Received:
> header, and I would suggest that it should not pass a message to spamd
> unless it has a Received header that was added by the local MTA;

A message will always have one of those.  That is what is so
mind-boggling.

> In the messages that fail in this manner is there only a single
> Received: header, for the local MTA hop?

Yep.  That's the one I'm absolutely certain must be present. 


/Per Jessen, Zürich


Re: Is there a way of forcing spamd not to process malformed messages? (NO_RELAYS, NO_RECEIVED etc).

Posted by John Hardin <jh...@impsec.org>.
On Mon, 30 Nov 2009, Per Jessen wrote:

>>>> On 30.11.09 16:41, Per Jessen wrote:
>>>>> Anyway, how about a way to make spamd refuse to process a message
>>>>> when it appears to to have any?
>>
>>> MTA is postfix, I call spamd directly using the spamc protocol (but 
>>> not spamc).
>
> I have my own smtp proxy which calls spamd. (amongst other things).

Then that is where the decision to scan or not scan must be made. spamd 
will scan whetever is sent to it.

That proxy shouldn't pass a message to spamd unless it has a Received: 
header, and I would suggest that it should not pass a message to spamd 
unless it has a Received header that was added by the local MTA; otherwise 
you will have to make your SMTP proxy add a fake local Received: header 
for spamd to interpret, including such data as the IP address of the 
client, its rDNS name, etc. - all the information that the _real_ MTA 
would put in the Received: header it adds.

WAG for the cause: you're scanning a message that is direct sender-to-you 
before your local MTA has had a chance to put in the first Received: 
header; in other words your glue is too early. In the messages that fail 
in this manner is there only a single Received: header, for the local MTA 
hop?

-- 
  John Hardin KA7OHZ                    http://www.impsec.org/~jhardin/
  jhardin@impsec.org    FALaholic #11174     pgpk -a jhardin@impsec.org
  key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
   The yardstick you should use when considering whether to support a
   given piece of legislation is "what if my worst enemy is chosen to
   administer this law?"
-----------------------------------------------------------------------
  15 days until Bill of Rights day

Re: Is there a way of forcing spamd not to process malformed messages? (NO_RELAYS, NO_RECEIVED etc).

Posted by Per Jessen <pe...@computer.org>.
Matus UHLAR - fantomas wrote:

>> > On 30.11.09 16:41, Per Jessen wrote:
>> >> I could, but it won't help - rest assured it has the headers.
>> >> Anyway, how about a way to make spamd refuse to process a message
>> >> when it appears to to have any?
> 
>> Matus UHLAR - fantomas wrote:
>> > which MTA do you use? How do you plug SA in?
> 
> On 30.11.09 17:06, Per Jessen wrote:
>> MTA is postfix,  I call spamd directly using the spamc protocol (but
>> not spamc).
> 
> directly from where? do you use spamd as SMTP filter? (can it be
> done?) 

Yes, it can be done - I have my own smtp proxy which calls spamd. 
(amongst other things). 

>> > where do those messages come from?
>> 
>> For instance a couple from msg.oleane.net, but it varies.
> 
> is that regular mail? Wouldn't it be better to exclude scanning mail
> that came from msg.oleane.net ?

Apart from very few internal exceptions, all mail is scanned - I
whitelist based on origin, but everything is scanned. 


/Per Jessen, Zürich


Re: Is there a way of forcing spamd not to process malformed messages? (NO_RELAYS, NO_RECEIVED etc).

Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
> > On 30.11.09 16:41, Per Jessen wrote:
> >> I could, but it won't help - rest assured it has the headers. 
> >> Anyway, how about a way to make spamd refuse to process a message
> >> when it appears to to have any?

> Matus UHLAR - fantomas wrote:
> > which MTA do you use? How do you plug SA in?

On 30.11.09 17:06, Per Jessen wrote:
> MTA is postfix,  I call spamd directly using the spamc protocol (but not
> spamc). 

directly from where?
do you use spamd as SMTP filter? (can it be done?)

> > where do those messages come from?
> 
> For instance a couple from msg.oleane.net, but it varies. 

is that regular mail? Wouldn't it be better to exclude scanning mail that
came from msg.oleane.net ?

-- 
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Quantum mechanics: The dreams stuff is made of. 

Re: Is there a way of forcing spamd not to process malformed messages? (NO_RELAYS, NO_RECEIVED etc).

Posted by Per Jessen <pe...@computer.org>.
Matus UHLAR - fantomas wrote:

> On 30.11.09 16:41, Per Jessen wrote:
>> I could, but it won't help - rest assured it has the headers. 
>> Anyway, how about a way to make spamd refuse to process a message
>> when it appears to to have any?
> 
> which MTA do you use? How do you plug SA in?

MTA is postfix,  I call spamd directly using the spamc protocol (but not
spamc). 

> where do those messages come from?

For instance a couple from msg.oleane.net, but it varies. 


/Per Jessen, Zürich


Re: Is there a way of forcing spamd not to process malformed messages? (NO_RELAYS, NO_RECEIVED etc).

Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
> d.hill@yournetplus.com wrote:
> 
> > Quoting Per Jessen <pe...@computer.org>:
> > 
> >> d.hill@yournetplus.com wrote:
> >>
> >>> Quoting Per Jessen <pe...@computer.org>:
> >>>
> >>>> I seem to be having more emails with NO_RELAYS than I normally see,
> >>>> and
> >>>> I'd like to havee spamd just refuse to process them.  That way
> >>>> they'd get left in the queue, and I'd have something to debug.
> >>>
> >>> NO_RELAYS indicates there are no Received headers:
> >>>
> >>>      http://wiki.apache.org/spamassassin/Rules/NO_RELAYS
> >>>
> >>> Have you checked the headers of the messages to see if there are
> >>> any?
> >>
> >> I know for a fact there are some, yes.
> > 
> > Post a message somewhere via pastebin or something that everyone can
> > take a look at.

On 30.11.09 16:41, Per Jessen wrote:
> I could, but it won't help - rest assured it has the headers.  Anyway,
> how about a way to make spamd refuse to process a message when it
> appears to to have any? 

which MTA do you use? How do you plug SA in?
where do those messages come from?
-- 
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
My mind is like a steel trap - rusty and illegal in 37 states. 

Re: Is there a way of forcing spamd not to process malformed messages? (NO_RELAYS, NO_RECEIVED etc).

Posted by Per Jessen <pe...@computer.org>.
d.hill@yournetplus.com wrote:

> Quoting Per Jessen <pe...@computer.org>:
> 
>> d.hill@yournetplus.com wrote:
>>
>>> Quoting Per Jessen <pe...@computer.org>:
>>>
>>>> I seem to be having more emails with NO_RELAYS than I normally see,
>>>> and
>>>> I'd like to havee spamd just refuse to process them.  That way
>>>> they'd get left in the queue, and I'd have something to debug.
>>>
>>> NO_RELAYS indicates there are no Received headers:
>>>
>>>      http://wiki.apache.org/spamassassin/Rules/NO_RELAYS
>>>
>>> Have you checked the headers of the messages to see if there are
>>> any?
>>
>> I know for a fact there are some, yes.
> 
> Post a message somewhere via pastebin or something that everyone can
> take a look at.

I could, but it won't help - rest assured it has the headers.  Anyway,
how about a way to make spamd refuse to process a message when it
appears to to have any? 


/Per Jessen, Zürich


Re: Is there a way of forcing spamd not to process malformed messages? (NO_RELAYS, NO_RECEIVED etc).

Posted by d....@yournetplus.com.
Quoting Per Jessen <pe...@computer.org>:

> d.hill@yournetplus.com wrote:
>
>> Quoting Per Jessen <pe...@computer.org>:
>>
>>> I seem to be having more emails with NO_RELAYS than I normally see,
>>> and
>>> I'd like to havee spamd just refuse to process them.  That way they'd
>>> get left in the queue, and I'd have something to debug.
>>
>> NO_RELAYS indicates there are no Received headers:
>>
>>      http://wiki.apache.org/spamassassin/Rules/NO_RELAYS
>>
>> Have you checked the headers of the messages to see if there are any?
>
> I know for a fact there are some, yes.

Post a message somewhere via pastebin or something that everyone can  
take a look at.


Re: Is there a way of forcing spamd not to process malformed messages? (NO_RELAYS, NO_RECEIVED etc).

Posted by Per Jessen <pe...@computer.org>.
d.hill@yournetplus.com wrote:

> Quoting Per Jessen <pe...@computer.org>:
> 
>> I seem to be having more emails with NO_RELAYS than I normally see,
>> and
>> I'd like to havee spamd just refuse to process them.  That way they'd
>> get left in the queue, and I'd have something to debug.
> 
> NO_RELAYS indicates there are no Received headers:
> 
>      http://wiki.apache.org/spamassassin/Rules/NO_RELAYS
> 
> Have you checked the headers of the messages to see if there are any?

I know for a fact there are some, yes.  


/Per Jessen, Zürich


Re: Is there a way of forcing spamd not to process malformed messages? (NO_RELAYS, NO_RECEIVED etc).

Posted by d....@yournetplus.com.
Quoting Per Jessen <pe...@computer.org>:

> I seem to be having more emails with NO_RELAYS than I normally see, and
> I'd like to havee spamd just refuse to process them.  That way they'd
> get left in the queue, and I'd have something to debug.

NO_RELAYS indicates there are no Received headers:

     http://wiki.apache.org/spamassassin/Rules/NO_RELAYS

Have you checked the headers of the messages to see if there are any?