On Mon, 26 Oct 2015, RW wrote:

On Mon, 26 Oct 2015 11:37:58 -0500 (CDT)
Shane Williams wrote:

I've created a header rule with "Received =~ /blahblahblah/", and I
just got a false positive on it when none of the Received headers in
the mail actually match.  I had a similar situation last week, and
(I think) found in the SA code where it will treat ezmlm headers as
if they were Received headers (which explained why it hit).

I had a quick look at the code and the only mention of ezmlm was
related to gated_through_received_hdr_remover() which looks for signs
that the email passed through something that might have stripped
headers. It tests the received headers, but doesn't modify them.

In my sleuthing, I found the part of Received.pm that looks for
"received" headers that don't actually start with "Received:" and adds
them on to the @hdrs array.  I thought I'd tracked down that one of
those alternate "received" headers was the ezmlm, which is related to
the email's path through various systems, so it made sense.

Unfortunately, with a weekend between when I looked at it and now, I
no longer see what led me to think that, nor can I remember which
email started my search, so it seems likely that I came to the wrong conclusion.

Instead, I think what was throwing me off is the fact that the
envelope-from gets checked as part of the Received header it appears
in, but then sendmail tears that out and puts it in the Return-Path:
header.  Add the fact that I'm running SA from a milter, and basically
I had no way to know exactly what the email looked like at the point
SA was analyzing it.  John Hardin's __ALL_RECEIVED rule suggestion
created the entries in the debug log that let me have a better idea
what SA was actually seeing and running rules against.


--
Public key #7BBC68D9 at            |                 Shane Williams
http://pgp.mit.edu/                |      System Admin - UT CompSci
=----------------------------------+-------------------------------
All syllogisms contain three lines |              sha...@shanew.net
Therefore this is not a syllogism  | www.ischool.utexas.edu/~shanew

Reply via email to