Permanent dialups + MX records

[Geoff]

If somebody's got a domain name and they want all email delivered to the local machine, the easiest way is to set up the dialup IP as a primary MX and another fast server as a backup. But this doesn't allow a limit on concurrent connections so it's preferable that the fast server be the primary MX record and automatically relay all mail to the dialup machine.

How do I set this up? Both local dialup machine and fast server are linux, fast server has postfix installed (which is actually pretty easy to use).

Geoff

[furrycat]

Easiest way is probably either to have the permanent dialup machine query the fast machine with fetchmail every five minutes or to advertise only the fast machine as an MX for your domain and have it forward all mail to your machine. In sendmail speak that would be "@yourdom.ain you@dialup.yourdom.ain" in the virtusertable.

I don't get it. What's the difference between five people all sending you mail at once and the upstream server sending you five mails at once? If it's fast the delay between messages will be small enough for that to be quite likely. Besides if the local machine IS permanently on then using all you bandwidth for mail is slightly less of an issue and you could do concurrency limitation with (for example) DJB's tcpserver from the ucspi-tcp package http://cr.yp.to/ucspi-tcp.html .
If you weren't online 24/7 you could say "It's all very well having a concurrency limit but I'll be swamped up to that limit when I dialup anyway as all the mail comes in" but having a permanent connection should balance it out a bit.

And another thing: how to expect to advertise to the outside world that your backup is the primary MX while convincing that backup that it's only a secondary? You'd need a separate DNS server just for that machine...

[Geoff]

The concurrency issue is that if the primary MX is the dialup machine then at 9am it gets swamped with everybody sending attachments and jokes around before they get some "real work" done. Unfortunately messages start timing out because there's so much traffic from different sources trying to get in.

The fast server only opens 2 concurrent connections to a host unless it senses it can handle more. So the mail actually makes it through rather than being hopelessly blocked by timeouts.

I don't think that you have to "trick" the server so much as set it up a certain way. surely there is a more elegant way than manually mapping every single address?

Geoff

[furrycat]

Well just do it the way I suggested at the top of my post. The company I used to work for had hundreds of customers set up this way. It works well especially if the local mailer (the dialup machine) is able to parse the original recipient from the message and deliver it to the LAN properly. fetchmail can do this as can other programs.

Of course, your users aren't sending their jokes and attachments to each other via the internet are they? They're using the local mailer aren't they? Which is a separate issue isn't it?

> I don't think that you have to "trick"
> the server so much as set it up a certain
> way. surely there is a more elegant way
> than manually mapping every single address?

Note that if you use pop-box solution you don't need to worry about dns. Let's ignore that and concentrate on the problem, which is to get the fast server to believe it's the primary MX. If it's the primary it will try to deliver mail to itself. So it needs to be a secondary. If it's a secondary the outside world will try to deliver to the dialup box first.
Hence I stand by my assertion that you need separate DNS for the local network. Call this a "trick" if you want. If you do that you don't need to "manually mapping addresses." If you go with the pop-box way you aren't "manually mapping addresses," you're delivering all mail to a single mailbox and having the dialup server parse it for recipients.

[Geoff]

I can't see how it'll work from what you've said.

The situation I've seen it in had an NT server running exchange eventually receiving the mail with their ISP being the primary MX and caching it. For all I know the ISP could be running on NT as well and if that's the case then you might as well throw the RFC books out the window.

Geoff