On Sun, Jul 02, 2006 at 09:13:34PM +0000, ed stuckems wrote: > you're not the first person to suggest postfix. It's a good, simple MTA. It's easy to get up and running, and it "emulates" sendmail (by providing a /usr/lib/sendmail binary), so you wouldn't be missing out on anything, except painful configuration headaches. :) > While I appreciate the advice (I know it sounds too cliche) but I > think my problem is not with sendmail itself but with the > operational details of sending mail I can sum those up quickly. For the general case of Internet mail: Your mail client creates a message. This consists of headers (like "From:", "To:", and "Subject:"), a body (big free-form block of text), an "envelope sender" (where bounces go to), and a list of recipients. The envelope sender is usually the same as the "From" header, and the recipient list is generally the same as the "To", "Cc", and "Bcc" headers combined. Neither of these are requirements. Unix-style mail clients generally use the sendmail style of sending. It runs /usr/lib/sendmail, which may be sendmail or may be something else that emulates sendmail, e.g. Postfix. It provides the envelope sender, the recipient list, the headers, and the body. When an MTA like sendmail, Postfix, etc. gets a mail, it may do one of two things. If it's configured to have a "smart host" / "relayhost", it will simply connect to that host, send all four pieces of info, and let that server handle everything. The server must be set up to allow relaying from the sending host's IP address. (Note that this is also what Windows mail clients do; they connect directly to their ISP's mail server, send all the info, and let the server handle it.) If not, it will go through the recipient list. Every recipient's domain is looked up, using a DNS query for "MX" (Mail eXchange) records. These denote mail servers set up to handle mail for that domain. It connects to each of these (port 25) and sends the envelope sender, the list of recipients that "reside" on that server, and the headers and body. If your ISP prevents you from connecting *out* on port 25 to anyone but their own mail server, then obviously, relaying is your only option. You can relay either through your ISP's mail server (recommended), or find a service that lets you relay via them on a different port. Ultimately, relaying is just a way of moving your mail, hop-by-hop, towards a server that can do the default (MX-based) "Internet-wide" distribution. That's the real heart of Internet e-mail. Relaying generally won't rewrite any of the info. If your ISP's mail server does indeed rewrite your "From:" header or envelope sender, then you've got a brain-dead ISP and should consider switching. :) Upon receiving mail, the server (by default) tosses the mail into each of the recipients' mailboxes, in a file under /var/spool/mail, or more recently, /var/mail. (Other configurable options include forwarding it on to some other address or server, running it through a filtering program like procmail, etc.) If you receive mail into a POP mailbox on a server, you can use "fetchmail" to retrieve it. This will connect to your POP account, download the mail, and "inject" it into your MTA addressed to your own account (via either of the means that mail clients use to send mail). Your MTA is then the direct recipient, and it will do what mail servers do upon receiving local mail, as described in the paragraph immediately above. If your ISP prevents you from receiving *inbound* connections on port 25, then you either need to have a "mail drop" (POP mailbox) somewhere (your ISP provides you with at least one) and use "fetchmail" (recommended), or you need to do what Bruce did -- have someone relay on a different port. > Put another way, I think I'd have the same questions/problems with > postfix. True, but the solution would be a lot simpler. ;) Modern distributions can often have a simple mail server completely configured just by providing correct answers to a few questions. > Security problems aside (sounds stupid, I know but ...) I've > invested some funds and time reading though texts on sendmail and > I'm not yet ready to abandon it and start from square one. Yes, Postfix/QMail/Exim are generally considered more secure than sendmail, in the "break into your computer via a code glitch" sense. One vulnerability that *every* MTA risks is being an "open relay". You'll note above that I said your IP needed to be authorised for a mail server to be willing to relay for you. There's a very good reason for this. If a mail server allows relaying from all IP addresses (or a broad range of them), then spammers can (and will) abuse that server to send their junk. If you run an open relay, you do the net a major disservice, your bandwidth usage will skyrocket -- slowing down normal use, and possibly costing you money for extra bandwidth on your next bill -- and the host you relay via will probably come down hard on you. Fortunately, most MTAs are fairly decently closed to relaying by default. And if you do need to mess with the relay access control, there are sites out there that will test your server for open relaying. It's a good idea to run one of these, even if you've never messed with your relaying configuration at all -- it may reveal inherent flaws in older MTA software. > So, with all due respect to someone who's advice has served me well > in the past, I'll take another kick at the sendmail can before > packing it in. I hope it's for the sake of historical education. :) In my experience, even with the big bat book on hand, switching from an established sendmail system to a brand new Postfix install was simpler in the long run than continuing to deal with sendmail. And I'm unconvinced that configuring sendmail teaches you more about mail itself than configuring any other MTA. The concepts are the same, the options are just distilled into easy-to-use configuration parameters, rather than annoying (IMO) m4 macros. Or worse, the sendmail.cf itself. However, feel free to continue using it. You just won't hear much from me (except on the details of SMTP itself) since I'm no longer a current user of the thing. :)
Attachment:
signature.asc
Description: Digital signature