[Vision2020] Blank and White lists

[Tony Ray]

This is Tony, Postmaster for Cactus TurboNet.

People have been sending me copies of emails from this list that are 
incomplete, misleading and inaccurate regarding how we handle email.  So 
let me set some things straight.

First, Cactus provides, free of charge, virus scanning and anti-spam 
filtering of email.  Virus scanning is done by aVast (who has won the 
European virus scanner face-offs the last two years running) and 
anti-spam filtering is done with SpamAssassin Version 3.  Our mail 
server is the Merak Mail Server, a very popular Windows mail server that 
is patterned after and compatible with Microsoft's Exchange server but 
doesn't have the ridiculous licensing restrictions.

There is a set of several thousand documents that define how computers 
should talk to each other over the Internet, generally referred to as 
the RFC's.  There are several regarding email servers and the primary 
one with respect to the treatment of spam is RFC 2505.  Merak uses the 
same interpretation of this document as does Microsoft for Exchange Server.

Black and White lists occur at three levels on Merak: user, domain and 
server.  User blacklists override domain blacklists and domain 
blacklists override global server blacklists.  So the user has first say 
on whether to accept an email or not.  (This is different from AOL, 
where AOL has first say.)  A problem arises when an email is sent, not 
to a single individual, but to a list of individuals.  The email server 
is given one copy of the email and a list of people to deliver it to.  
When given the list, one recipient at a time, the sender's address is 
checked against the recipient's blacklist.  Only two responses are 
possible: "OK" and "Access denied".  If it is "OK", the next recipient's 
blacklist is checked and so on.  If it is "Access denied" then the email 
is rejected.  So you see, only one recipient needs to reject an email 
for the email server to reject the email.

FSR's email server had been blacklisted by SpamCop so many times in the 
past that I finally had to put in a bypass for the moscow.com domain at 
the global level.  It has been there for several years.  So we, Cactus, 
are not blacklisting any mail from moscow.com.  But, if a TurboNet 
subscriber blacklists Vision2020 at moscow.com, then they override my 
global bypass for that email address whenever they are included as a 
recipient.  As it turns out, a couple people who thought they were 
whitelisting Vision2020 accidentally blacklisted it instead.  This was 
the cause of a recent problem with Cactus TurboNet subscribers receiving 
Vision2020.  But this need not have happened.

Our list server at Cactus, by default, sends email, not as a list but to 
each recipient individually.  This way, one person's blacklist does not 
affect any other person.  More than that, email servers can reject a 
list if it is too long or has too many bad email addresses.  Sending the 
emails to each individual separately solves these problems too.  So, as 
you can see, our list server is less likely to have its email rejected 
than the Vision2020 list server.  When I talked to FSR, I was told that 
they believed their list server could also send emails individually, but 
they didn't want to do it that way.

Spam is with us and it is the responsibility of Postmasters to configure 
their email servers and list servers so that they do not accidentally 
trigger anti-spam filters.  Some ISP's do not want to take the time or 
responsibility to guarantee that their customer's email has the best 
chances of being delivered.  They prefer to blame problems that can be 
avoided on the recipient's ISP.  That is not our attitude at Cactus and 
never has been.

Now, I personally do not agree with the way blacklists are handled by 
the Merak email server (and many others that follow Microsoft's 
interpretation).  Last summer I contacted the Merak developers about 
it.  When an email server is given a list of recipients, it creates a 
list of "delivery paths" for the email message.  Delivery paths can be a 
list of mailbox locations or forwarding addresses.  I told them I would 
prefer a blacklisting recipient was just skipped by not adding a 
delivery path for them.  They replied that it would be a violation of 
the RFC's so it could not be the default action.  It would violate the 
RFC's because the email server would be, in effect, saying it accepted 
the email for the recipient, when, in fact, it hadn't.  It could also 
not return a "user unknown" because it does know the recipient.  
However, they would consider these responses as an option for a future 
update.

Happy surfing,

--Tony, Postmaster for Cactus TurboNet.