lee wrote:
> On Tue, Feb 24, 2009 at 04:17:12AM +0800, W B Hacker wrote:
>> lee wrote:
>>> Hi,
>>>
>>> since I can't just deny messages that contain a virus (using
>>> fetchmail), I'm trying to rewrite the Subject: header instead:
>>>
>>>
>>> warn malware = *
>>> add_header = Subject: *VIRUS* $h_Subject:
>>>
>>>
>>> However, this eventually adds a second Subject: header to the mail,
>>> instead of rewriting an existing Subject:. (Are multiple Subject:
>>> headers allowed in a mail?)
>>>
>>> Is it possible to rewrite headers within ACLs? How would I do that?
>>>
>> message = Subject: *Suspect* $h_Subject:
>>
>> ..works for me.
>>
>> But that is on spam score.
>
> Hmm ... I tried it, but it also adds another Subject: header same as
> add_header does --- which seems weird, but I haven't found out what
> "message" exactly does. My understanding is that "message" is to allow
> supplying a customized message to an error report for instances when
> and error is generated, like mail being denied or deferred. But I
> didn't really find that in the documentation. In any case, I wouldn't
> ever expect it to add a header line to a message.
Right side does that ....
Anyway ... well-documented for many years that all this stuff *adds* a
header, does not replace it.
Look further into the archives and docs, and find the how-to remove the
original header.
It isn't necessarily recommended, as we (MTA operators) are expected to
try hard to NOT alter incoming characteristics/ backtrail.
OTOH, the recipent's MUA will display the most-recently-added
'Subject:', so it works well enough to leav to original unless they do a
'view source' or have full-headers on-screen.
Few do either.
>
> Did you check if you get multiple Subject: lines that way? Maybe your
> MUA displays only the last one that appears within a mail, not the
> first one or another?
>
See above. 'twas ever thus....
>> So long as you have enough control over Exim to do something like the
>> above, I haven't a clue what makes you think you cannot drop
>> known-WinCrobes on the floor of the Data Centre, rather than passing
>> them on to WinLusers - flagged or not - as they WILL open them and WILL
>> spread them.
>>
>> Your upstream's ToS probably *require* that you not propagate those.
>
> It's because I'm getting mail with fetchmail to read it with mutt as a
> user on the machine running exim. If I was receiving mail directly, I
> would deny messages that don't pass the scanner in the ACL instead of
> accepting them --- but if I would deny messages using fetchmail, I
> would create useless bounces. However, it's also possible to receive
> mail directly (using dynDNS entries), and that makes it desirable to
> deny messages in ACLs.
>
That makes no sense at all to me.
The method you use to *retrieve* mail has nothing to do with what
filtering you ask Exim to do before making it available.
> Though I could just drop them as a blackhole, I don't want to do that
> because that would be the same as losing mail, which, of course, is
> unacceptable.
>
Who told you that spam / WinCrobes from zombots was considered 'mail'?
And no need to accept, then blackhole.
That *is* deceptive.
Better to reject up-front. A 'proper' correspondent will then know what
you considered rude. A zombot won't care - but at least you've made
the attempt.
Exim is as good as it gets for doing that intelligently.
Providing the 'wetware' tells it to in a sane manner...
> If I had other users than myself and couldn't deny mail that doesn't
> pass the scanner, I'd have to think of something else ...
>
'something (anything) else might serve you better already...
Just *where* is this Exim instance running?
Starting to sound as if it is on a laptop in your backpack on 'Road
Runner' dial-up. ....
Bill
