macdiggs.com

I've been getting absolutely crazy and steadily increasing volumes of so called "Undelivered mail" spam to my main mailbox for last few months (1000+ mails a day) - even with SpamAssassin installed, and I really don't have time to search for email blocking solutions all day long (and the solution for this particular problem is pretty complicated afaik) - so yesterday I have decided to move all my email handling to Google Apps service, which offers handling your domain's email on Google's servers (so I can keep using my primary mike@//this-domain// addres like nothing happened)

The Google Apps offers email service just like gmail, and some other services I didn't need, as well. Google offers several options for the service, and the Basic version is free. I went with the Basic one, of course, as I'm absolutely fine with the features it offers. All I needed is large email box (and it's currently 6G+ on Google), IMAP access, and - most important - good spam filter (and this is the killer feature of Google's mail!)

The switch was very easy and took me may be about 15 minutes in all. I signed up for Google Apps for my domain, then went to my registrar's site and switched MX records (these records are responsible for telling the world which server handles your email) to Google ones (and left all other records as is, as I have no need for Google to host my web site). Then of course I have removed macdiggs.com from local domains list in sendmail (so that email from my co-worker who uses the same server to be delivered to the new location)

In a few hours, once DNS records propaged, I started getting all my email to Google.

And the result is absolutely fantastic! All that "undelivered/delivery error email" just automatically goes to spam folder (and is further automatically piped to the Trash folder via "is:spam" filter). All the unfiltered spam just suddenly disappeared from my mailbox. And this is very, very, very big stress relief. My mailbox is 99.9% spam-free again, after several annoying months..

Sure, there are some changes for worse, the biggest one being my email server becoming much slower to access than the dedicated one I have used until now, but I'm fine with the change, given positive outcome of the switch.

Yes, you can do it very easy and fast if you have Webmin installed on your server.

Go to Servers -> Sendmail Configuration -> Sendmail Options and make sure that SMTP port options parameters are set to:

Name=MTA
Port=587, Name=MSA, M=E

Just like on the screenshot below:

Click "Save and Apply" button and you're done. Now your mail server will accept mail on both 25 and 587 ports.

I have migrated all my Ruby on Rails system from Fedora Core 6 to RedHat 4.5 recently, and everything was fine, except for that the feature of blogging by email was broken (got a phone call today about that).

I use standard sendmail/procmail integration feature to receive mail to a designated address,  and then pipe it into Rails Mailer's receive function.

So, it looks like that in my /etc/mail/virtusertable:

m@example.com        examplemobile

this way all email which is coming to m@example.com address will be forwarded to system user called examplemobile.

In order to process the mail further and pipe it into my Rails script, I have the following setup in my /etc/aliases file :

examplemobile: "|/usr/local/bin/ruby /var/www/html/examplesite/current/script/runner -e production 'Mailman.receive STDIN.read'"

This setup worked perfectly on Fedora, but broke under RedHat. What's the problem? I was getting the following errors in my maillog:

Feb 13 11:45:33 appserv1 sendmail[32000]: m1D2jXJw032000: from=<xxxxxx@c.vodafone.ne.jp>, size=397, class=0, nrcpts=1, msgid=<20080213114719020972.1b6f@0016E68C4270>, proto=SMTP, daemon=MTA, relay=mmrts035p01c.softbank.ne.jp [123.108.236.87]
Feb 13 11:45:33 appserv1 smrsh: uid 8: attempt to use "ruby /var/www/html/examplesite/current/script/runner -e production 'Mailman.receive STDIN.read'" (stat failed)
Feb 13 11:45:33 appserv1 sendmail[32001]: m1D2jXJw032000: to="|/usr/local/bin/ruby /var/www/html/examplesite/current/script/runner -e production 'Mailman.receive STDIN.read'", ctladdr=<m@examplesite.com> (8/0), delay=00:00:00, xdelay=00:00:00, mailer=prog, pri=30623, dsn=5.0.0, stat=Service unavailable

The problem turned out to be in sendmail setup under RedHat was more secure than the one I had in Fedora. Specifically, this has to do with smrsh (or Sendmail Restricted Shell) thingy. More info about it here. Basically, sendmail only allows piping to programs which (or aliases to them) are present in /etc/smrsh directory.

Since I only use ruby to pipe to, I have added a symbolic link to it inside the /etc/smrsh directory:

[mike@appserv1 smrsh]$ pwd
/etc/smrsh
[mike@appserv1 smrsh]$ ls -l
lrwxrwxrwx  1 root root 19 Feb 13 11:50 ruby -> /usr/local/bin/ruby

Everything works as it should now, and our mobile-blogging users are supposedly happy again :)

I've been getting a strange "User unknown" error from sendmail today, when everything should have worked fine and even though users did exist. Here's some info on the problem's source and solution.

We have a domain called "talentnavi.biz", and I was asked to add a new subdomain to that domain ("kansai.talentnavi.biz"), and add new email addresses for several users who will be using that domain. I have setup everything properly on the server site by adding users and updating local domains and virtusers lists, however, when I was trying to test the delivery of the messages, I was getting "User unknown" errors and my emails to the newly-created mailboxes were bounced back.

I checked my mail server's logs, but there were of no help at all. After some googling, I found a very nice solution! In order to see how an email to a particular email address gets delivered, you should run the following command as root:

sendmail -d60.5 -d27.2 -bv info@example.com

So, in my case the command and output were as follows:

[root@me-ja mike]# sendmail -d60.5 -d27.2 -bv info@kansai.talentnavi.biz
map_lookup(dequote, mike, %0=mike) => NOT FOUND (0)
map_lookup(host, kansai.talentnavi.biz, %0=kansai.talentnavi.biz) => talentnavi.biz. (0)
map_lookup(dequote, info, %0=info) => NOT FOUND (0)
map_lookup(virtuser, info@talentnavi.biz, %0=info@talentnavi.biz, %1=info) => NOT FOUND (0)
map_lookup(virtuser, @talentnavi.biz, %0=@talentnavi.biz, %1=info) => NOT FOUND (0)
alias(info)
info@kansai.talentnavi.biz… User unknown

So, turns out that I have incorrectly configured my DNS records. They were set up like the following:

talentnavi.biz A 123.123.123.123

talentnavi.biz MX talentnavi.biz

kansai.talentnavi.biz CNAME talentnavi.biz

So, by default, the kansai.talentnavi.biz was aliased to talentnavi.biz, and since I didn't have a separate MX record for kansai.talentnavi.biz, the talentnavi.biz was used for mail delivery.

mike-meja:~ mike$ host -t mx kansai.talentnavi.biz
kansai.talentnavi.biz is an alias for talentnavi.biz.
talentnavi.biz mail is handled by 20 talentnavi.biz.

Therefore, the all email which was sent to "info@kansai.talentnavi.biz", was actually attempted to be delivered to "info@talentnavi.biz", because there was no separate MX record for the kansai. subdomain.

The solution is of course to add :

kansai.talentnavi.biz MX kansai.talentnavi.biz

Record to DNS server, and everything should work fine.