On Fri, 4 Mar 2016, Alex wrote:

Hi,

I have a legitimate mail that received 2.8 points, making it spam, as
a result of what appears to be a false positive with DOS_OUTLOOK_TO_MX

http://pastebin.com/dbm2Q4k6

There doesn't seem to be any desktop system involved, just direct
communication with the sender's service provider. Is this the cause?

Is it possible this rule has a problem, or perhaps just the score is too high?

Thanks,
Alex

Usual mail flow is:
  sender-PC -> sender-ISP-MSA -> (zero or more intermediate MTAs -> )
recipient-MX-MTA -> (zero or more internal recipient-MTAs -> ) delivery system

Assuming the message started at a sender's PC you should see 2 or more external network transmission operations before it gets in the recipient-MX-MTA system. (IE two or more systems listed in the "X-Spam-RelaysUntrusted" header.)

If the message originated in a server (EG a MSP) rather than a PC, you might only see one external network transmission (but a bit uncommon for legit mail).

Looking at your pasetbin example, I see only one system in the "X-Spam-RelaysUntrusted" header and ALSO a "X-Mailer: Microsoft Office Outlook 12.0" header. (which implies that the message originated on a PC, who runs Outlook on a server?).

So the inference is that a PC handed the message directly to the recipient's MX-MTA, thus the firing of that rule.

I'm not trying to defend the score value, just saying that the rule firing seems reasonable (IE doesn't look like a FP).

The one way that it could be a FP is if the sender's emitting MTA/MSA system deliberately stripped off all transport information to hide the original source. That seems like a rare case. If it were common (I'm not aware of having seen it before) the masscheck scoring process should have driven down the score of that rule.

--
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{

Reply via email to