Mast Kalandar

bandar's colander of random jamun aur aam

Thu, 30 Jul 2009

< The National Policy on Open Standards | · | Thanks IMSc (and Chennai too) >

Mail and Spam handling

mail, politics, software, sysadmin [link] [comments ()] [raw]

The following text can be classified as a rant so before plunging in I must underline that I have great sympathy for those who administer mail servers and have to deal with complaints about excessive spam on the one hand and about lost mail on the other.

The current fulminations are the result out of spending half a morning and a good bit of an afternoon debugging the problems arising from the following sequence of events:

  1. A couple of days ago one of our users had his webmail session hijacked. This hijacked session has been used to generate a mountain of spam over the last few days.
  2. As a consequence of this activity our site was (justifiably) put on a blacklist by some DNSRBL services.
  3. Some of the domains with which we exchange a lot of e-mail (in both directions) stopped accepting SMTP traffic from us since they "subscribe" to these DNSRBL services. So outgoing mail from us to these domains started bouncing.
  4. We use callout verification of senders. Such verification started failing for incoming mail from domains that refused our SMTP connections (once the cached verification data had expired). So incoming mail from these domains to us also started bouncing.

Of course, there is an all round "blame game" going on about who is responsible.

  1. The big bad bunch of spammers who are making everyone miserable.
  2. The user who used a buggy browser.
  3. The incorrect defaults of the webmail program that does not impose timeouts for session keys.
  4. The lack of system log monitoring that let this go on (for more than a day!) without anyone noticing.
  5. The blind use of DNSRBL's by some mail configurations.
  6. The low cache timeouts for sender verification data by other mail configurations.

However, here is a basic lesson for mail administrators everywhere who are tempted to give the knee-jerk response "Go fix your spamming mail servers!" to mail administrators whose domains they have blacklisted.

It is illogical to reject out-of-hand incoming mail from the same mail exchangers that you are trying to send mail to.

A second lesson is that the net gain in all of this lies with the large Web 2.0 mail sites (like Google and Hotmail). Few dare to blacklist them and they employ an army of people to monitor logs and configurations. It is then only natural that users gravitate to use these sites for all their mail needs.

In the long run that is not a Good Thing(TM).


< July 2009 >
    1 2 3 4
5 6 7 8 91011

2016, 2015, 2014, 2013, 2012, 2011, 2010, 2009, 2008, 2007, 2006, 2005, 2004, 2003, 2002, 2001, 2000, 1999, 1997, 1995,