D-man, (and others),
|On Tue, May 21, 2002 at 09:36:41PM +0200, Mark Martinec wrote:
|> 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.)
Not necessarily - depends on how MUA passes message to MTA.
MUA can pass envelope addresses separately, otherwise MTA must derive
them by parsing RFC2822 header, and remove Bcc while doing it.
This is covered by:
RFC2821 / APPENDIX B / 1.
... Any BCC fields SHOULD then be removed from the headers.
RFC2822
3.6.3. [...] In the second case, recipients specified in the
"To:" and "Cc:" lines each are sent a copy of the message with
the "Bcc:" line removed as above, but the recipients on the "Bcc:"
line get a separate copy of the message containing a "Bcc:" line.
|> 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.
| [...]
| It would be better to have envelope handing in the MTA and Message
| handling in the other stuff.
Return-path should only be added to the header by the delivery agent.
If filtering is done on a mail hub, it must _not_ add the Return-path
just to satisfy some scanner's curiosity, as otherwise we'll end up
with two such headers.
Envelope-To or similar may only be added by the final delivery
agent, individually for each recipient. Mail hub must not add such
header, as it would violate the privacy and reveal the full list
of envelope recipient to all recipients, which is not permitted.
I find it too limiting to restrict spam filter to require it to see
only RFC2822 message and ignore other information if available.
True, it is not available in all configurations, but if it _is_ available
(like when spam filter is called from the central mail hub), any additional
information may be of value. If it were phases of the Moon to have influence
on spam-score, so why not.
I think it is valuable information for a spam filter for example:
- to see there are 20 recipients listed in the envelope
(this may not be apparent from the header due to grouping (undisclosed
recipients), Bcc, or just plain spammers' tricks
- to see the local part of the envelope sender address
ends in "-admin" or "-owner", or starts with "owner-"
- to see the envelope sender domain has no counterpart in From, Sender,
Errors-to or Reply-to (this may still be valid, but more often than not
it is an indication of spam or a mailing list)
|> I would be very happy to move the envelope sender whitelisting
|> off the amavisd-new and into SA, where it really belongs.
| The envelope recipient is useless for checking spam -- it is always you :-).
I had in mind the envelope sender address,
but as far as recipient address is concerned - it is 'you', but not
necessarily only you. If the filter is positioned at a mail hub
and not just-before the final delivery, there may be more than one
recipient address in the envelope (and not necessarily also in the header).
| If you want to whitelist an envelope
| sender, then don't feed the message to SA in the first place.
Some arguments for not having similar whitelists in two places:
- easier to administer in one place only. Depending how SA is called
from MTA, it may not be much more costly doing it in SA (such as
in the configuration where Mail::SpamAssassin module is invoked
from amavisd-new (virus checker daemon in Perl));
- despite whitelisting, I may still want to have SA scores added
to the header, as well as X-Razor-id header with SHA1 hash to facilitate
user reporting of spam to Razor database servers, so it would still
be desirable to call SA even for whitelisted senders;
- I find it much more predictable and easier to collect a list
of friendly envelope sender addresses, than trying to guess for each
mailing list in which header what address is placed. There are cases
where some ML user names the mailing list only in Bcc, so the
only header with a reference to ML is some List-id or such.
On the other hand, envelope sender address is always predictably there.
As stated above, Return-path may not already be available at the time
spam checker is invoked;
- although not currently implemented in SA, I see two uses of
whitelists (having previous experience as a Razor-only user):
* unconditionally permitting a message from whitelisted addresses,
as is traditionally understood
* turning off certain tests for certain sender addresses;
this is typically used to turn off Razor check for popular mailing lists
(or giving it a lower score), as Razor is more likely to produce
false positive for such mail.
In summary:
- adding API mechanism to SA to make possible to pass envelope information
to SA during a call to Mail::SpamAssassin::NoMailAudit->new (or otherwise)
is probably very easy to implement, and would potentially contribute
valuable information to SA rules (and whitelists)
- having all information and tools in one place makes it easier for
administrators (and users: per-user settings) to manage such a system.
Regards
Mark
--
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!! Mark Martinec (system manager) tel +386 1 4773-575 !!
!! J. Stefan Institute, Jamova 39 fax +386 1 2519-385 !!
!! SI-1000 Ljubljana, Slovenia [EMAIL PROTECTED] !!
!!!!!!!!!!!!!!!!!!!!!!!!!! http://www.ijs.si/people/mark/ !!!!
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
