January 17, 2011
Avoiding spam filters
Installed the SMTP module and am optimistic my problems are now ALL solved. To wit:
Received-SPF: pass (google.com: best guess record for domain of www@[server1].umich.edu designates [ip1] as permitted sender) client-ip=[ip1];
Received-SPF: pass (google.com: best guess record for domain of [site_email]@umich.edu designates [ip1] as permitted sender) client-ip=[ip1];
Received: (from www@localhost)
by [server1].umich.edu (188.8.131.5260308/8.12.9) id p0OIMVP3003713;
Mon, 24 Jan 2011 13:22:31 -0500
Received: FROM umbs.lsa.umich.edu ([server1].umich.edu [ip1])
By [server2].umich.edu ID 4D3EE9D9.6ED0B.21456 ;
25 Jan 2011 10:18:49 EST
Email I sent to www-sig:
A not insignificant portion of auto-emails coming from my website (Drupal install hosted on an ITS Virtual Server) are being flagged as spam. The emails are generally user-confirmation or password reset emails. Is there anything I can do to increase the likelihood that these emails go through to the recipient without being caught in spam filters?
See below the fold for the responses I received. I will focus on changes I've made next.
Change subject line of auto-emails
- Original: Account details for [username] at University of Michigan Biological Station
- New: Registration confirmation at the University of Michigan Biological Station
- Original: Replacement login information for [username] at University of Michigan Biological Station
- New: Replacement login information at the University of Michigan Biological Station
Basically, I'm hoping that removing the username from the mix will do the trick. I've also removed username references from the body of these emails.
Check to see if the email servers I'm using are flagged as spam sources
1) Look at email header to determine IP address of email servers. This page is a good source of information.
2) Plug IP Addresses into a web application that checks against listings of spam sources.
3) ITS provides a similar service for spam blockers on the UM campus.
None of the servers I am using were flagged so I'm going to focus on altering the structure of the auto-emails at this point.
I'm not optimistic that the above changes are going to have much affect and it is too important that our emails get to where they need to be.
This thread discusses DNS report results that may indicated spam filtering problems.
Change "From" email address:
There are several things you can do. First is to avoid the use of words, or combinations of words, which can trigger the Bayesian filters. Lists of common spam words are available via Google. Another thing is to be sure that your outgoing emails are properly formatted. Formatting errors with RTF/HTML/etc. can flag messages. Header formatting is also an issue. Another is of course attachments.
One thing you can do is check the headers of the messages that get flagged. Many filters attach a header (e.g. X-SPAM) with the "hit count" (instances of triggering the filters) for each test. That might tip you off as to what in particular is causing the messages to be flagged.
Hope that helps. Please let me know if there is anything else I can do.
Do what Jaime already said first (and note that if the message recipient uses the ITS IMAP service, spam factors are off by default, but the recipient can have them turned on for all future messages by contacting firstname.lastname@example.org).
In addition to what [the previous emailer] already said, you can check the IP address from which your message is being sent (N.B.: NOT the IP address of your website, nor your domain name, but the IP from which the email is actually originating) to see if it has a bad reputation as an IP address from which spam originates. Check both the realtime blackhole lists that U-M uses ( http://spambusters.mail.umich.edu/troubleshoot/blockstatus/ ) as well as others worldwide (google for both "rbl" and "ip reputation" to find quite a few to check). If you discover you're on a blacklist or the IP in question has a bad reputation, contact email@example.com and work with them to resolve the issue.
I advise against pursuing things such as SPF or DKIM for your own domains outside of umich.edu unless you have hard evidence that using one of these will in fact result in significantly better message tagging and acceptance by major ISPs. U-M uses neither, by the way, due to cost/benefit reasons, and I have not heard of any problems resulting from the lack up to this point.
I hope this is useful.
*Emphasis added by me.
Posted by kkwaiser at January 17, 2011 09:00 AM