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/
jhar...@impsec.org FALaholic #11174 pgpk -a jhar...@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
