Outlook oddities #2

[Steve Campbell]

Glenn Steen wrote:
> 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
>   

I wasn't aware that these RRs weren't treated as normal "Reply To" 
messages. Turns out, after doing more digging, that Outlook 10 and 
Outlook 12 handles these properly. Outlook 11, which is common on a lot 
of our machines, breaks things. Some Outlook 9 problems are showing up, 
but I don't have enough info to say that all 9's are broken.

So the problem definition is mostly Outlook odd-numbered versions 
produce odd results. Outlook, itself, is an odd program. Apparently, 
some oddball programmer at Microsoft forgot to include fixes from 
version 10, which fixed version 9, into version 11, and remembered it 
for version 12. Guess by now you've figured out that the next version of 
Outlook is going to be broken just because of karma.

For some reason, no one is requesting these RRs today, so I'm not 
getting a lot to monitor for fixage.

Thanks for all the help.

steve