http://bugzilla.spamassassin.org/show_bug.cgi?id=3021





------- Additional Comments From [EMAIL PROTECTED]  2004-02-12 14:37 -------
Created an attachment (id=1765)
 --> (http://bugzilla.spamassassin.org/attachment.cgi?id=1765&action=view)
patches to implement this (see comment)

This attachment contains the diffs for existing files that are being changed.
The next attachment contains the test file and its data, which are all new
files.

This modifies the eval test for whitelist_from_rcvd and def_whitelist_from_rcvd
so that as it looks for an address being in the whitelist it also notices if
the address matches but the relay doesn't. If that is the case and there are no
sender addresses found to be in a whitelist, then it is considered a forgery,
triggering one of two new rules that this adds, FORGED_IN_WHITELIST or
FORGED_IN_DEF_WHITELIST.

There is a new option in Conf.pm called whitelist_allows_relays which has the
same syntax as whitelist_from. It is to be used when an address listed in
whitelist_from_rcvd or def_whitelist_from_rcvd may send non-spam mail through
another mail relay that is not specified and therefore can't be used for
whitelisting. The whitelist_allows_relays indicates that such mail should not
be labeled as a forgery, but it is not whitelisted.

Note: I don't like the name whitelist_allows_relays. I kept typing
whitelist_allow_relays and forgetting whether I had named it with or without
the 's'. Somebody should come up with a different name for that option that is
not so subject to confusion before checking this in.

The scores I assigned to the two new rules are arbitrary. There should be some
discussion about what they should be. I do think that they have to get
arbitrary assigned scores and not be part of the GA, similar to the scores for
the other whitelist related rules.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Reply via email to