Hello Daryl,
Tuesday, March 8, 2005, 8:44:43 PM, you wrote:
DCWOS> Robert Menschel wrote: DCWOS> <snipped a little for brevity>
Summary: A group of volunteers will maintain a collected/distributed whitelist, using SpamAssassin's whitelist_from_rcvd capabilities, similar to (but in the opposite direction as) William Stearns' collected/distributed blacklist at http://www.stearns.org/sa-blacklist/sa-blacklist.current.cf
DCWOS> Don't forget about the new whitelist_from_spf capability that DCWOS> should be in the next major release.
Not forgetting about it. Looking forward to it. However, hoping to have a first whitelist.cf file out before 3.1 is officially released, we can't very well include whitelist_from_spf rules in there, at least not immediately.
Of course! I wasn't sure on the time line for this whitelist, or 3.1 for that matter.
However, thinking back, we have the ability in SA to do conditional rules now, yes? So we could (using meta language rather than the actual SA language):
if version < 3.1.0 then put here the whitelist_from_rcvd rules for which we don't have spf else put here the whitelist_from_spf rules for these sources end put here the whitelist_from_rcvd rules where spf doesn't apply.
I'll look into that capability and begin testing it.
I believe you'd need to use two separate if structures:
if (version >= 3.001000)
whitelist_from_spf
endifif (version < 3.001000)
whitelist_from_rcvd
endifDCWOS> I think we'd like to get away from whitelist_from_rcvd if
DCWOS> possible for domains that appear to have sensible SPF records
DCWOS> (records that actually list their hosts and don't use ?all,
DCWOS> etc). ...
Agreed.
DCWOS> For info on whitelist_from_spf (and def_whitelist_from_spf) DCWOS> implementation see bug 3487.
Thanks for the pointer. This functionality is active in the current svn bleeding edge version, yes? If so, then perhaps later this week I can download that and begin playing with it.
I haven't commited it yet, but the latest patch in the bug will probably be what is used unless somebody thinks of something I missed.
It'd be extremely unlikely that the actual rule form would change from what it is now: whitelist_from_spf [EMAIL PROTECTED]
...just like whitelist_from & blacklist_from.
Assumption: This activity will focus only on public newsletters,
services, etc., which normally do not contain any private
information. Therefore there will not be any privacy or
confidentiality concerns for the great majority of emails from
these sources.
DCWOS> What about emails from banks etc? I'd think they'd be a good DCWOS> candidate for something you want to whitelist based on their DCWOS> received headers or SPF.
Excellent class of whitelist entities, and with high privacy/confidentiality concerns. I don't want people sending banking userids or passwords or such around by email.
We'll have to come up with some guidelines concerning how to communicate and validate those.
[Question to the devs: would you agree this is a valid use for the def_whitelist_from_rcvd rule?]
DCWOS> I don't see a problem with it, although we may want to create DCWOS> an alias for it, such as sare_whitelist_from_(rcvd|spf), to DCWOS> prevent confusion between entries included in the distribution DCWOS> with those available from SARE.
That would be excellent. I don't see any way for SARE to create such an alias ourselves (though it might be feasible via plugin) -- what would be involved in getting such aliases defined?
And to generalize the alias name more, maybe call it
contrib_whitelist_from_rcvd (and _spf) describe: contributed whitelist entry
There are various ways to do it, if the rest of the devs feel there is a need for it.
Any submission which already matches a def_whitelist_from_rcvd rule within the SA distribution will be identified and ignored (after response back to the submitter). (We are not going to try to develop pre-3.0.0 files.)
DCWOS> There aren't too many of them so it shouldn't be a problem. DCWOS> I'd suggest listing those domains (along with new domains as DCWOS> added) on a web page at your site, along with the info on how DCWOS> to submit new domains.
Rather than maintain the rules and then separately a list of domains, IMO it'd be easier to simply make sure the rules are ordered by domain name, and make the online link point to the rules file itself.
I'd rather go to the slight extra effort of making the rules file more readable than try to keep two different files in sync.
Well, if it comes to the point where you implement a database for submissions, you can automatically generate both the rules page and the submission page / duplication checks rather trivially.
Can anyone think of any guidelines to be added or changed?
DCWOS> You might want to setup a web form for submissions. You could DCWOS> use it (well, the script behind it & a database) to DCWOS> automatically filter out duplicate submissions -- but still DCWOS> tally submissions for a domain.
Yep, good enhancement to the idea. We'll use email to get started (since there's nothing to build), but a web form is a good way to go.
DCWOS> Then again I don't know how many submissions you are expecting, DCWOS> so that may be overkill.
Over time I would expect many hundreds -- all banks, credit unions, airlines, hotel chains, retail chains, newspapers, major magazines, major NPOs, etc.
Bob Menschel
Daryl
