Avoiding spam with procmail, aliases, and virtual user table
Thursday, August 31. 2006
I am very protective of my personal email account. I don't usually want to give it away for anything other than to someone that I know personally. I am doing this to keep it from getting spamed, and it has been largely successful. I should probably have a server-based spam filter like spamassasin, and a probably even a virus scanner. But since I have my own mail server at home, setting up a spam filter feels like a pain and a big hassle. Plus mostly we runs linux (Fedora distro) anyway so we are less worry about viruses. Even when we use Windows, we use sane email program; my wife and I are also very cautius about opening any attachment (and we open them on linux if we are a little bit unsure). So as you can see, we hope that we can just use common sense to fight againts spams and viruses. But recently a very small amount of spams have managed to get into my personal mailbox, so I may just have to bit the bullet at some point and install a spam filter anyway, when the numbers start to get annoying.
Anyhow, one of the advantageous of having one's own mail server is that one can easily create (and remove) "pseudo" mail accounts. So that's what my mode of practice has been. For example, for creating account at Amazon, I would create a pseudo account something like "my-amazon-email@mydomain.com". The same thing for my bank accounts, credit card accounts, etc, I would have a "personalized" account for each and every single one of them. Sometimes I create a single account for registering at several different sites (ie. Slashdot, Digg), so it all depends on my mood and my discretion at the moment. I also create several throw-away accounts like "myself001, myself002, mywife001, etc" which we can use when we're pressed to give out email address to uncertain entity while travelling. This is done using Sendmail virtual user table for my domain which then route the email message to a valid local user.
The advantage of doing this is at least two fold. First, if the "personalized" email account get spammed, I can just remove them and create a new one easily. Secondly, I know which what service / website I registered that email accounts for, so if gets spammed, I could justify having a very strong suspicion that the company either intentionally spamming me, or sell / give out my email account to other companies / services. Then I will just have to make sure that I won't have anymore bussinesses with it, infact I would go so far as discouraging any people that I know that are considering doing bussiness with the company / website / service.
So this practice has been working well for me, except for one loophole. Having my own domain, I need to put an email address for domain registration, which is available publicly via Whois lookup. So this address really becomes the source of nearly all spams coming into my mailbox, other than the spam attempts to find random valid addresses on my domain (ie. "accounting, billing, sales, ..."). For all of that, I have a catch-all trap in my virtual user table that goes to an alias called "spam", which then re-route the messages to /dev/null.
The email account for domain registration, -- let's call that "dom_reg@mydomain.com"--, is routed directly to my local user from the virtual user table. So I've been trying to block this using several procmail recipes, but somehow some spam messages are clever enough to get though. My procmail recipes for this account basically say "if the email is to dom_reg AND from My Registrar, deliver to Inbox, otherwise send to /dev/null." But the spams come in like this, the "To: " header would make it seems that it's addressed to "accounting@mydomain.org", yet somehow it's sent to my domain registration email account. So the recipes never catch it! I am still not sure how this happens, but it does. The problem is, I have to filter on the "To:" header also in the recipes, otherwise the recipes will catch all messages send to my personal email account. If only I could directly invoke these recipes when the message comes, -- ie. go a level higher on when to filter these messages --, I'd be just fine.
But I could ! It just occured to me, that I could invoke procmail directly from the aliases file. So what I needed to do is to create alias for this dom_reg@mydomain.com and changed the virtual user table so that mail goes to this address is routed to the alias. So here is what I did.
First created a directory on the system where specific promail recipes for this situation would go, I called it /etc/procmailrc.d (following Redhat/Fedora convention for directory containing configurations). Then I created recipe file for this situation, basically it says "If the mail is from My Registrar, accept it, otherwise, throw it away." Now the problem is how to call procmail from /etc/aliases.
Sendmail uses smrsh to invoke programs, which is a restricted shell for security. It can only executes programs that are in /etc/smrsh directory (or symbolically linked from there). So I could create a symlink to /usr/bin/procmail in /etc/smrsh, but that would be the best way since procmail then can execute any program. So my solution is to create yet another wrapper for procmail under /etc/smrsh, which call procmail with the correct procmailrc as argument. So I have the following files:
/etc/smrsh/procmail-dom_reg:
OK, so now in the /etc/aliases, I have the line:
And for completeness, in my virtual user table files, which is /etc/mail/virtusertable, I have the following:
and /etc/procmailrc.d/dom_reg contains something like:
So there you have it, a creative way of using virtual user table, aliases, and procmail. All this trouble is actually to fight spams that are coming to dom_reg account, and to catch email from my registrar which probably only comes once a year, if at all, to remind me when my domain registration is about to expire
. Now I'm starting to wonder if installing a real spam filtering software would actually be easier.
Anyhow, one of the advantageous of having one's own mail server is that one can easily create (and remove) "pseudo" mail accounts. So that's what my mode of practice has been. For example, for creating account at Amazon, I would create a pseudo account something like "my-amazon-email@mydomain.com". The same thing for my bank accounts, credit card accounts, etc, I would have a "personalized" account for each and every single one of them. Sometimes I create a single account for registering at several different sites (ie. Slashdot, Digg), so it all depends on my mood and my discretion at the moment. I also create several throw-away accounts like "myself001, myself002, mywife001, etc" which we can use when we're pressed to give out email address to uncertain entity while travelling. This is done using Sendmail virtual user table for my domain which then route the email message to a valid local user.
The advantage of doing this is at least two fold. First, if the "personalized" email account get spammed, I can just remove them and create a new one easily. Secondly, I know which what service / website I registered that email accounts for, so if gets spammed, I could justify having a very strong suspicion that the company either intentionally spamming me, or sell / give out my email account to other companies / services. Then I will just have to make sure that I won't have anymore bussinesses with it, infact I would go so far as discouraging any people that I know that are considering doing bussiness with the company / website / service.
So this practice has been working well for me, except for one loophole. Having my own domain, I need to put an email address for domain registration, which is available publicly via Whois lookup. So this address really becomes the source of nearly all spams coming into my mailbox, other than the spam attempts to find random valid addresses on my domain (ie. "accounting, billing, sales, ..."). For all of that, I have a catch-all trap in my virtual user table that goes to an alias called "spam", which then re-route the messages to /dev/null.
The email account for domain registration, -- let's call that "dom_reg@mydomain.com"--, is routed directly to my local user from the virtual user table. So I've been trying to block this using several procmail recipes, but somehow some spam messages are clever enough to get though. My procmail recipes for this account basically say "if the email is to dom_reg AND from My Registrar, deliver to Inbox, otherwise send to /dev/null." But the spams come in like this, the "To: " header would make it seems that it's addressed to "accounting@mydomain.org", yet somehow it's sent to my domain registration email account. So the recipes never catch it! I am still not sure how this happens, but it does. The problem is, I have to filter on the "To:" header also in the recipes, otherwise the recipes will catch all messages send to my personal email account. If only I could directly invoke these recipes when the message comes, -- ie. go a level higher on when to filter these messages --, I'd be just fine.
But I could ! It just occured to me, that I could invoke procmail directly from the aliases file. So what I needed to do is to create alias for this dom_reg@mydomain.com and changed the virtual user table so that mail goes to this address is routed to the alias. So here is what I did.
First created a directory on the system where specific promail recipes for this situation would go, I called it /etc/procmailrc.d (following Redhat/Fedora convention for directory containing configurations). Then I created recipe file for this situation, basically it says "If the mail is from My Registrar, accept it, otherwise, throw it away." Now the problem is how to call procmail from /etc/aliases.
Sendmail uses smrsh to invoke programs, which is a restricted shell for security. It can only executes programs that are in /etc/smrsh directory (or symbolically linked from there). So I could create a symlink to /usr/bin/procmail in /etc/smrsh, but that would be the best way since procmail then can execute any program. So my solution is to create yet another wrapper for procmail under /etc/smrsh, which call procmail with the correct procmailrc as argument. So I have the following files:
/etc/smrsh/procmail-dom_reg:
exec procmail /etc/procmailrc.d/dom_reg
OK, so now in the /etc/aliases, I have the line:
dom_reg: |promail-dom_reg
And for completeness, in my virtual user table files, which is /etc/mail/virtusertable, I have the following:
dom_reg@mydomain.com dom_reg
and /etc/procmailrc.d/dom_reg contains something like:
:0
* ^From:.*godaddy\.com
! my_real_email@mydomain.org
So there you have it, a creative way of using virtual user table, aliases, and procmail. All this trouble is actually to fight spams that are coming to dom_reg account, and to catch email from my registrar which probably only comes once a year, if at all, to remind me when my domain registration is about to expire
. Now I'm starting to wonder if installing a real spam filtering software would actually be easier.
Comments
Display comments as
(Linear | Threaded)
Hi, searching for a way to block spams via virtusertable and procmail I stumbled across your site. I looks like you have a solution for my needs. One comment and one question:
1. Comment: You wondered about why a lot of spam comes through which seems to be adressed to "accounting@yourdomain.org" but isn't catched neither by your virtual user table nor by your procmailrc. I think, there could two things going on: (a) The Spammers use a forged To-Header while directing the mail via Bcc: to your "dom_reg"-account and probably additionally (b) the spammers use a specific To-Header to surpass simple procmail recipes. At my site
I have a recipe like
:0
*^To: sales@mydomain.de
/dev/null
It catches all mails with a To-Header like:
To: sales@mydomain.de
What it doesn't catch are mails with
To:
So I think you have to filter not only for "accounting@yourdomain.com" but also for "".
But maybe there is another problem at your site ...
2. Question: You wrote you are using "a catch-all trap" in your virtual user table. Can you describe how you do that exactly? Do you list all adresses that are spammed like , and direct them to a single alias "spam" und use a .procmailrc for this account, which just writes to /dev/null? Or is there a way to send those mails to /dev/null directly from within your virtual user table?
Best regards, Christian
1. Comment: You wondered about why a lot of spam comes through which seems to be adressed to "accounting@yourdomain.org" but isn't catched neither by your virtual user table nor by your procmailrc. I think, there could two things going on: (a) The Spammers use a forged To-Header while directing the mail via Bcc: to your "dom_reg"-account and probably additionally (b) the spammers use a specific To-Header to surpass simple procmail recipes. At my site
I have a recipe like
:0
*^To: sales@mydomain.de
/dev/null
It catches all mails with a To-Header like:
To: sales@mydomain.de
What it doesn't catch are mails with
To:
So I think you have to filter not only for "accounting@yourdomain.com" but also for "".
But maybe there is another problem at your site ...
2. Question: You wrote you are using "a catch-all trap" in your virtual user table. Can you describe how you do that exactly? Do you list all adresses that are spammed like , and direct them to a single alias "spam" und use a .procmailrc for this account, which just writes to /dev/null? Or is there a way to send those mails to /dev/null directly from within your virtual user table?
Best regards, Christian
Comments (3)
Sorry, my second example of a To-Header didn't go through. I meant
To: < sales@mydomain.de >
But without the spaces after < and before >.
Christian
To: < sales@mydomain.de >
But without the spaces after < and before >.
Christian
Comments (3)
Hi Christian,
1. Yes, I suspect that the spammer forged the To header and use bcc. I checked my procmail recipe again and I have wildcard (*) at the beginning or the To but not the end, so you're probably right that I also need to filter for the "".
2. For the catch all, in my virtual user table I have something like:
@domain.org spam
This means everything else for domain.org that is not explicitly stated on the virtual user table will go to that catch-all trap. Take a look at this also: http://www.sendmail.org/tips/virtual-hosting.html
Then, in /etc/aliases, something like:
spam : /dev/null
I don't think you can redirect directly to a file from virtusertable (I am using sendmail). It has to map to local user or alias.
Hope that helps.
RDB
1. Yes, I suspect that the spammer forged the To header and use bcc. I checked my procmail recipe again and I have wildcard (*) at the beginning or the To but not the end, so you're probably right that I also need to filter for the "".
2. For the catch all, in my virtual user table I have something like:
@domain.org spam
This means everything else for domain.org that is not explicitly stated on the virtual user table will go to that catch-all trap. Take a look at this also: http://www.sendmail.org/tips/virtual-hosting.html
Then, in /etc/aliases, something like:
spam : /dev/null
I don't think you can redirect directly to a file from virtusertable (I am using sendmail). It has to map to local user or alias.
Hope that helps.
RDB
Comment (1)
Hi Reuben,
thanks for the explanation! What I didn't know was how to use /etc/aliases to solve this problem. I'll change my settings accordingly!
Thanks again.
Christian
thanks for the explanation! What I didn't know was how to use /etc/aliases to solve this problem. I'll change my settings accordingly!
Thanks again.
Christian
Comments (3)
I would agree that the likely source of your reception is via bcc.
a suggestion on the use of aliases though: append some additional text to the address, like so:
dom_reg.local-budiardja |/usr/local/bin/procmail -m /path/to/your/rccfile
and be sure to specify that entire LHS string as the RHS of your virtualusertable entry.
The reasoning for this is that the aliases file will otherwise automatically expand the valid addresses at your domain, and if you host more than one domain, the aliases will appear to be valid addresses as each one. lets's say you have two domains and there's a webmaster alias -- unless something overrides the alias, that same alias will be used for both domains. Of course, even the obtuse alias is globally valid on your system, but it's much less likely to be stumbled upon.
I have a very different approach to individual signups. As I manage my own DNS, I can create temporary subdomains - MX records which I can purge after say 9 months. I'll actively use them for 6 months, then replace them, but only delete the host entry after about 9 (allowing my mail use to overlap a bit).
The reasoning for this is actually quite simple: if you use your base domain for everything, you cannot escape the barrage of email attempts at the host. You may fend them off with DNSBLs or post-reception content filtering, but you're still dealing with the connections. If however, after some time, the very hostname the compromised email address utilizes NO LONGER RESOLVES, then the spammer isn't even connecting to your system to make the attempted delivery (there's still a nominal hit somewhere along the line for the DNS lookup, but that's trivial - AND the result is cached).
09A.domain.tld MX 10 yourmailhost
09B.domain.tld MX 10 yourmailhost
You needn't try to disguise the hostname relation to the year, and if at some point you get premptive spam at a newly created host, at THAT point, you can decide to use arbitrary words biannually ("freak -> noob -> expand -> whatever"). Thus far, spammers are an opportunistic lot - they harvest addresses and try dictionary attacks, but they're not spending their time trying to figure out how any one individual site deals with spam.
a suggestion on the use of aliases though: append some additional text to the address, like so:
dom_reg.local-budiardja |/usr/local/bin/procmail -m /path/to/your/rccfile
and be sure to specify that entire LHS string as the RHS of your virtualusertable entry.
The reasoning for this is that the aliases file will otherwise automatically expand the valid addresses at your domain, and if you host more than one domain, the aliases will appear to be valid addresses as each one. lets's say you have two domains and there's a webmaster alias -- unless something overrides the alias, that same alias will be used for both domains. Of course, even the obtuse alias is globally valid on your system, but it's much less likely to be stumbled upon.
I have a very different approach to individual signups. As I manage my own DNS, I can create temporary subdomains - MX records which I can purge after say 9 months. I'll actively use them for 6 months, then replace them, but only delete the host entry after about 9 (allowing my mail use to overlap a bit).
The reasoning for this is actually quite simple: if you use your base domain for everything, you cannot escape the barrage of email attempts at the host. You may fend them off with DNSBLs or post-reception content filtering, but you're still dealing with the connections. If however, after some time, the very hostname the compromised email address utilizes NO LONGER RESOLVES, then the spammer isn't even connecting to your system to make the attempted delivery (there's still a nominal hit somewhere along the line for the DNS lookup, but that's trivial - AND the result is cached).
09A.domain.tld MX 10 yourmailhost
09B.domain.tld MX 10 yourmailhost
You needn't try to disguise the hostname relation to the year, and if at some point you get premptive spam at a newly created host, at THAT point, you can decide to use arbitrary words biannually ("freak -> noob -> expand -> whatever"). Thus far, spammers are an opportunistic lot - they harvest addresses and try dictionary attacks, but they're not spending their time trying to figure out how any one individual site deals with spam.
Comment (1)
About Me
This is my personal blog, a subset of my personal website. I am a graduate student in Computational Astrophysics, currently working on my dissertation for my doctoral degree. I am a computer hobbyist, mainly with interest in Linux and open source software. I am also interested in the subject of science and religion, especially from Christianity / Mennonite point of view. On my leisure, I play music, read, or just enjoying time with my wife.
Categories
Bookmark
Show tagged entries
Quicksearch
Syndicate This Blog
Powered by
Often time I have a group of people that I constantly exchanging emails with. This group is sometimes informal enough, fluid enough (a changing memberships or only temporary), or small enough to make it not worth the trouble to create a mailing-list for, Comment (1)
Tracked: Sep 06, 01:14