יום ראשון, אוגוסט 23, 2009

HOWTO: Sendmail authentication against your ISP

After the trouble I had with incoming mail, I decided to migrate my sendmail configuration to use the big ISP mail server -- this documents establishing SMTP authentication against an ISP.

What I already had:
  • SMART_HOST configured in my /etc/mail/sendmail.mc:

  • define(`SMART_HOST',`smtp:mail.actcom.co.il')

  • Masquerade definitions, as I use a fictitious domain on my internal network.

  • MASQUERADE_AS(`actcom.co.il')dnl The domain of my ISP
    ... some optional features...
    FEATURE(masquerade_entire_domain)dnl
    ... The domains that are masqueraded
    MASQUERADE_DOMAIN(localhost.localdomain)dnl
    MASQUERADE_DOMAIN(my.internal.domain)dnl

  • The sendmail m4 macro package installed. In Fedora it is packaged
    as sendmail-cf
The only changes in /etc/mail/sendmail.mc were:
  • Updating the SMART_HOST to the new mail server (out.bezeqint.net).
  • I did not need to update the MASQUERADE_AS, since my mail address remained the same.
  • Adding a new FEATURE:

  • FEATURE(authinfo)dnl


Now I had to create a new file /etc/mail/authinfo and make it readable only by root:
cd /etc/mail && touch authinfo && chmod 600 authinfo
The content of this file (for my ISP) is:
AuthInfo:server "R:realm" "U:user" "P:pass" "M:mechanisms"
Details:
  • server - the name or IP of your ISP mail server (out.bezeqint.net for my ISP)
  • realm - the domain of your ISP (bezeqint.net for my ISP). I first didn't set it and it caused obvious auth failures, as the default was my fictitious internal domain.
  • user - for me it was different than 'oron' because the ISP modified the internal names of the users when it acquired Actcom.
  • pass - guess what?
  • mechanisms -- the default is a list of secure mechanisms (GSSAPI, etc.) obviously my ISP doesn't use anything like that so I had to give it explicitly as: "M:LOGIN PLAIN"
  • The quotes around each items are mandatory!
For anyone who want the gory details, just make sure you have the sendmail-cf package installed and search authinfo (ignoring case)
in /usr/share/sendmail-cf/README.

Last but not least. They seem to be using Postfix, but don't support TLS, which means the users password is transmitted in the clear every time she send mail. Please don't tell this to Wietse_Venema so he won't get a heart attack.

Big ISP's and what they cost us

I was using the same small ISP (Actcom) since ~1997. An important reason was that it was founded and managed by Amir Plivatzky, which at the beginning of the 80's while studying for Masters degree at the Technion managed the BSD-4.1/4.2 systems in the Technion -- For me as an EE freshmen at the time, people like him should be blamed for sending me down the *NIX road ;-)

About a year and a half ago, Actcom was bought by one of the big players in our ISP pond (Bezeqint). I was worried, but since they promised to keep the status-quo, decided to wait and see how it goes.

To their credit, they did try to leave things as they are, but without the original knowledgeable people that's hard to do.... so things slowly deteriorated:
  1. One of the first things to go was the web-app enabling a customer to securely manage its own mailbox. So to change your mailbox password, you have to call their support and tell them the wanted password :-O
  2. Webmail (which I use when out of country) was also migrated to their systems. Problem? the link to it leads you to an 'http:' login screen -- as I don't want to send my password as cleartext across the globe it became a non-starter for me.
Last week I got another blow. Some mails I expected from people didn't show up. At first I didn't suspect anything unusual since I did get other mails. A few days later I dug my maillog and saw fechmail got a lot of 'Host unreachable' errors. A quick perl script found that in the last two weeks, only 3 out of 20 connection attempts per hour succeeded. The total amount of received mail was also very low. Emergency mode now starts... calling their support.

They were clueless as expected but they do deserve to be credited as they were:
  1. Quick to answer the phone, polite and making an effort to help the best they could.
  2. Didn't panic when finding out I didn't use Outlook but fetchmail (which they didn't heard of before). I explained them the problems and walked with them over the tests I did (resolving the mail server name to IP, pinging, testing the IMAP port number via telnet, testing POP3 as fallback).
They admitted they can barely manage Actcom's original mail server and advised me to work against their normal mail server. A quick change in my fetchmail parameters and >700 delayed mails landed in my mailboxes (I host 3 of them).

All good? Not so quick. Two days later I found that my mails stream is thin again. My logs show it was an authentication problem now. Quick call to the support line. The result? I had to change the internal user name of the mailbox with some prefix they assigned to Actcom customers. Still a bit unexplained:
  • How it managed to suck >700 mails with the original names?
  • Of the three mailboxes, two authenticate only with the new name, one authenticate only with the old. Go figure...
As you can understand I'm in damage control mode now and I haven't even thoroughly tested yet the outgoing mail path...

One small benefit. I wrote a quick and dirty logwatch plugin for fetchmail so at least I'll be alerted on time. I'll upload it somewhere (and try to push it to fetchmail Fedora package) when things calm down a little.