On Tue, May 21, 2002 at 09:36:41PM +0200, Mark Martinec wrote: | | Rob> Now SPAM's getting through this "loop hole". Is there any way to | | Rob> whitelist based upon Recipient to:, or am I just screwed? | | | | Can't you just define a "header" rule, such as | | | | header REALLY_ME To =~ [EMAIL PROTECTED]/ | | describe REALLY_ME To: indicates it's for me | | score REALLY_ME -5.0 | | The SMTP envelope address (sender and recipients) is quite | a different thing than the RFC822 addresses inside the mail header.
Yes.
| it is a requirement for a MTA that it removes 'Bcc:' addresses from
| the header!
NO. It is a requirement that the MTA *NOT* do anything to the data in
the DATA part of the SMTP session apart from escaping a line beginning
with '.' and prepending a Received: header. It is the MUA's
responsibility not to insert that header in the first place. (It's
kind of obvious that you don't send someone data you don't want them
to have.)
| I would be very happy to move the envelope sender whitelisting
| off the amavisd-new and into SA, where it really belongs.
It would be better to have envelope handing in the MTA and Message
handling in the other stuff. If you want to whitelist an envelope
sender, then don't feed the message to SA in the first place. The
envelope recipient is useless for checking spam -- it is always you
:-).
| - while at it, there may be an opportunity for MTA to pass the IP address
| of the originating SMTP host to a content filter - might be useful,
| as otherwise this information is (partly) lost - can be available
| in the 'Received:' headers, but there is no guarantee
There is a guarantee if you configure your MTA properly. You'd have
to do that anyways even if some feature was added to SA.
| and no simple way to parse them.
Yeah, that's the problem with data that isn't strictly specified.
| There is probably an extra benefit of having envelope addresses
| available to SA rules.
Maybe. The simplest way is to tell your MTA to add the Return-Path:
and Envelope-To: headers and make rules for them in SA.
-D
--
[Perl] combines all the worst aspects of C and Lisp: a billion different
sublanguages in one monolithic executable.
It combines the power of C with the readability of PostScript.
-- Jamie Zawinski
GnuPG key : http://dman.ddts.net/~dman/public_key.gpg
msg05274/pgp00000.pgp
Description: PGP signature
