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 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
