Outlook oddities #2

[Glenn Steen]

On 18 March 2010 13:45, Steve Campbell <campbell at cnpapers.com> wrote:
> Thanks Glenn,
>
> Glenn Steen wrote:
>>
>> On 17 March 2010 20:45, Kevin Miller <Kevin_Miller at ci.juneau.ak.us> wrote:
>>
>>>
>>> Steve Campbell wrote:
>>>
>>>>
>>>> The warning in MW indicates "no watermark or sender address" so I
>>>> think I can do a hex dump on the quarantined file and see what's
>>>> causing the corruption.
>>>>
>>>> I'm still a little confused about having the address whitelisted from
>>>> which these users are sending, and why SA complains since it isn't
>>>> supposed to be checking these because of that.
>>>>
>>>
>>> I never noticed it before, but all the whitelisted entries have SA scores
>>> associated with them.  Apparently SA runs regardless, but just passes them
>>> if whitelisted...
>>>
>
> Kevin,
>
> I'm not sure this is true in this case. The IP is whitelisted, but the SA
> stuff is short-circuited by the From: and watermark problems. No SA score is
> shown on these RR thingys.
>
> Thanks.
>>>
>>> ...Kevin
>>>
>>
>> If you have the "Always include SA score" setting (probably named
>> slightly different... Bad memory day:-), MS will have to run SA for
>> everything, whether it is used as a "sorting criterion" or not.
>>
>>
>
> I do have that set, but apparantly, the watermark section takes precedence
> over the SA section.
>>
>> That Steve has problems with the watermark feature (which is an MS
>> feature) marking some return receipts as spam ... kind of suggest the
>> sollution itself, doesn't it? Juts put a similar ruleset on that as
>> you have for the spam whitelist ... and presto, problem solved;-).
>>
>>
>
> I had already considered this as a "workaround" but was hoping to find a
> solution to the real problem (Outlook). Of course I'm still wondering what
> is going on that makes a RR differ from normal mail sent and why something
> is missing or corrupt to make MS/SA think there is a problem in the first
> place.
>
> Based on what I see, the From is corrupt or something and the watermark
> isn't there. I might be looking at the files at the wrong time (in the
> timeline of the email). But shouldn't these RRs go through the same process
> as a normally sent email?
All "MAILER-DAEMON"-type mails have an empty sender. This is
stipulated in the RFC(s).
Spammers tend to abuse this, so hence the watermark feature ... to
battle that. It does so by checking adding a "watermark header" to all
outgoing mail. When some MTA "on the net" have a need to return a
message, the watermark header must be preserved (stipulated by the
same RFCs), so that MS can check all the "empty senders" mails for a
valid watermark.
Normally this works nicely.

But when an agent misbehave, like yours do, then the sender will be
empty, but the watermark will not be preserved... Leading to MS
treating it as spam (or whatever you've configured it to do:-).

So the problem, in a nutshell, is that your internal server/clients
aren't preserving all headers for the RRs. DSN/NDNs are probably not
affected, but you can do a simple search in MailWatch to see if they
are... I know for certain that MS Exchange 2k3 will abuse this for OoO
type messages... But I don't care that much about those:)

If anything, look at stopping RRs altogether. I do by so by
intentionally breaking RFC-compliance... I let Postfix "ignore" those
headers;-).

>>
>> The settings to look at/put a ruleset on are (one of, depending on the
>> effect you want):
>> Check Watermarks With No Sender (to simply check/not check watermarks
>> for the whitelisted IP addresses)
>> Treat Invalid Watermarks With No Sender as Spam (to choose a different
>> action... "nothing" seems appropriate for the whitelisted ones:-)
>> But don't use "Use Watermarking" for the whitelist, since that would
>> effectively turn the feature off for relayed mail;-).
>>
>> Cheers
>>
>
> I'm going to try and see what the above will accomplish. Again, thanks for
> the help.
>
> steve
>

Cheers
-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se