On Thu, Jun 26, 2003 at 05:23:25PM -0400, Yakov Shafranovich wrote
I would like to provide a generic proposal for consent-based system as per
charter:
I have an account at clss.net. They run a modified Qmail that parses a
config file in the user's home directory. The filter rules are applied
during the SMTP transaction, just after the RCPT: stage.
1. Users and/or ISP define rules and filters to filter incoming email.
Rules/filters are decided by end users and ISPs, and are not mandated.
Yup. There's a "user friendly" frontend menu. I prefer to manually
edit the filter file with vim for maximum flexibility.
2. For each email user, the MUA or the ISP maintains a whitelist
of trusted senders, blacklist of blocked senders and a graylist
of unknown senders. Whitelisted senders go the inbox, graylisted
senders go to the bulk folder, and blacklisted senders are either
in the spam folder or erased.
Because the blocking takes place during the SMTP transaction, the
sending MTA gets the big 550. Rejected emails are *NOT* "bounced" to
innocent 3rd parties whose email addresses have been forged by spammers.
- Whitelisted email goes through with a free pass, regardless of any
other rules it may trip.
- Blacklisted email gets a 550 message, in most cases containing a
pointer to one of my webpages that has a current unfiltered
temporary alternate email address. This is a safety net for
legitimate senders who get caught as collateral damage by the DNSbls
or other blocking rules I use. Spammers don't seem to read reject
messages, so that filter bypass hasn't been abused yet.
- Greylist... I define to mean that portion of messages that are not
in my whitelist, but do not trip any of my blocking rules. Those
messages are accepted just like regular email.
3. Whitelists are not only a list of email addresses of trusted
senders, but to avoid sender spoofing also have additional features
such as digital signatures, certificates, passwords, tokens, etc.
Since clss.net's system makes the decision before the DATA: stage,
this additional stuff is not available. IP address and rDNS can be
used, however.
4. Additional automatic whitelist rules are defined as such email from
trusted senders (e.g. Habeas) is automatically goes to the inbox unless
blacklisted, etc. C/R systems are also integrated and upon receiving a
positive response automatically whitelist the sender.
I do it all manually.
5. Additional automatic blacklist rules are defined such as email coming
from known open relays is blocked.
That's what DNSbls are for. They update as new open relays and
proxies are discovered. They also automatically de-list with closure.
I do have to manually add/delete countries that I block using the
zz.countries.nerd.dk superzone. I started off with South Korea, China,
Taiwan, and Nigeria. As Nigerian scammers realized Nigeria was blocked
to hell and back, they moved to the Netherlands, which I also had to
block. France and Isreal have recently popped up on my spam radar.
6. Whitelists, graylists and blacklists are stored hashed or encrypted
to protect privacy.
That may generate a misleading warm fuzzy feeling, but it's useless.
A traffic log of your emails will show what you accept/reject.
--
Walter Dnes <waltdnes(_at_)waltdnes(_dot_)org>
Email users are divided into two classes;
1) Those who have effective spam-blocking
2) Those who wish they did
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg