[dev] Fwd: IMP message header triggering spamassassin
Kevin Myer
kevin_myer at iu13.org
Tue May 3 05:34:34 PDT 2005
Perhaps I'm wrong but I see the current header as being sort of the equivalent
of a X-Forwarded-For: header for proxied HTTP requests, but in a mail
context. But I would agree that the current behavior is wrong. MTA's
generally report
who a message is to, instead of who a message is from, so I'd vote for
s/sender/receiver/ in the code. The Horde MIME Library is attempting to
emulate a MTA by generating a Received: header. I wouldn't see that as a
configurable preference though.
Privacy implications are a reasonable consideration too - however, the
place to
do anything about this is not in Horde/IMP but with your MTA. If you want to
masquerade/hide/strip out Received: lines, or do other mangling of headers,
thats the MTA's job. Although I could also make an arguement that a
standalone
mail client wouldn't add its own Received: headers to a message prior to
passing it on to a SMTP server...
That being said, Spamassassin is just doing what its told. I'm not sure if
you're running it or your company is running it but if you don't like its
behavior, change the rule scoring. Or whitelist your company. You'd have the
same issue if you used a standalone mail client and sending mail through your
company's server, from home. It may be that changing the "for" from sender to
receiver causes your SA to kick in a much higher negative score to start with,
resulting in the message not getting tagged as spam.
Kevin
--
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13 http://www.iu13.org
More information about the dev
mailing list