RE: virtual mail domains... long-winded response
[ snip ]
>> We do virtual domains with POP3 here by using a custom local mailer
>> and a modified version of qpopper.
>>
>> The first step is to create a virtual_pop transport, then a virtual_pop
>> director, e.g.
>This seems crazy to me. Originally, this was that approach I was going to
>take. However, I didn't want to be forced to run a different MTA other
>than smail. Not that smail's all that great, but it's the beast I'm
>familiar with. Also, smail supposedly supports virtual domains, but you
>have to run multiple copies of it... which wasn't all that appealing.
>What I eventually settled on was to have it all done by elm's filter(1).
>The reason for this was because I realized that I didn't need virtual
>POP interfaces, I needed virtual addresses and that was it. In fact, I
>concluded that having accounts like "info@somecompany.com" was a bad
>idea since they're not directly mapped to an individual and that the
>login and password would be probably known by several individuals at
>SomeCompany as the job of handling the "info" mail got passed on from
>employee to employee.
>So, I figured that what I really wanted were *aliases* that would send
>"info@somecompany.com" to some single individual on the system. I was able
>to pull this off by aliasing names like "info" and "sales" to myself. Then,
>in my .elm/filter-rules file, I'd put lines like:
>if To contains "client1.com" and not To contains "jemenake" forward jjones
>if To contains "client2.com" and not To contains "jemenake" forward bsmith
>...
>This worked like a charm! However, I wanted to take myself out of the loop.
>Now, filter supposedly allows for you to specify a certain rules file with
>the "-f" option. So, I tried putting the following in my /etc/aliases file:
>info: "|/usr/bin/filter -f /etc/virt-aliases.filter"
>But this doesn't seem to work (smail and filter are REAL finnicky about
>permissions and ownerships of files and what UID they're running as).
>Any ideas or comments?
>- Joe
Well as a customer (actually one of your customers Joe) that uses virtual domains for e-mail, I prefer to have my mail dumped into one mailbox; provided that I have the right information in the mail header to route the message locally.
I have several Debian systems running masquerading and diald connected to some of the major ISPs in the Boise, Idaho area. They each support a network of between 6 and 20 Macs and PCs and use virtual domain service for their e-mail service from their ISP.
To let the Macs and PCs on the LAN poll for mail whenever they want (without dialing to the ISP every time they want to check for e-mail), I've set up the Debian systems as sort of a mail gateway. All the clients point to the Debian boxes for their SMTP and POP mail servers.
For outgoing mail, I run smail on the Debian box setup to relay mail to the ISP's SMTP mail server once every 30 minutes or so. I've seen two different ways ISPs handle incoming mail for virtual domains.
The most common method I've seen for handling incoming virtual domain e-mail, is to dump all mail into a single pop account on the ISP's mail server. Unfortunately, I don't believe there is a standard on how to write the mail headers for the incoming mail messages so they can be reliably routed.
Without getting into a really long-winded explanation about mail headers and MTAs and sendmail.cf files, to be able to reliably route mail locally from a multi-drop box, the MTA needs to write the SMTP recipient name somewhere in the mail header.
The ISPs that I've dealt with generally write the SMTP recipient name in the "for" field of the "Received" line and/or in the X-Envelope-To: line. Unfortunately, the ISPs don't always get the recipient name into one of those fields correctly (although Cyberhighway now seems to get the X-Envelope-To: correct all the time).
I've been working with the author of fetchmail (which I believe is now the best pop retrieval program going) to make multi-drop mail routing as reliable as possible. With (what I deem) proper configuration of the MTA at the ISP, fetchmail should be able to route mail from a multi-drop mailbox with 100% reliably. (If you'd like to talk about what I think is proper configuration of the MTA for virtual domain support, e-mail me directly)
Given the popularity of virtual domain e-mail hosting, there should probably be an RFC for this sort of thing.
The other way I've seen an ISP deal with virtual domain hosting for a dial-up account is to assign a static IP address to the dial-up account and then play some tricks with DNS and the MTA to get the mail to its final destination. Basically, the ISP assigns a static IP address to the dial-up account and puts two MX records in their DNS for the mail domain, like:
mydomain.com. IN MX 0 mystaticip.myisp.com.
mydomain.com. IN MX 10 mailhost.myisp.com.
If the link is up when mail comes in, it goes to the right place. If the link is down, the mail will be sent to the ISP's mailhost and queued. This particular ISP uses qmail which supports an SMTP command QSND mydomain.com which does a queue run for mail bound to mydomain.com. The QSND command is run by the Debian box in its ip-up script. (Supposedly sendmail supports a similar command, I don't believe smail does but I think exim might.)
This is a clean solution if the customer is running an MTA on their PPP interface. I don't think many ISPs are setup to do this however.
I'd sure like to hear from other ISPs and linux masquerading/diald users out there and how they handle virtual domains. Using linux with masquerading and diald is becoming a very popular way to connect small LANs to businesses so I think its something that ISPs should support well.
More ideas and comments?
Al Youngwerth
alberty@apexxtech.com
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: