Re: [Asrg] Consent Proposal

[Walter Dnes <[e-mail]>]

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 <[e-mail]>
Email users are divided into two classes;
1) Those who have effective spam-blocking
2) Those who wish they did

_______________________________________________
Asrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg