On Sun, Aug 05, 2001 at 10:35:50PM -0400, Russell Nelson wrote:
> A user on this mailing list has a problem. He has a fast non-static
> IP ADSL connection, which is listed on the DUL. The non-default route
> was a slow second internet connection with a static IP and which was
> not listed on the DUL. He has several choices that I can see:
>
> 1) Try to get his fast connection removed from the DUL. That's not
> acceptable since he doesn't have a fixed IP address.
>
> 2) Let his SMTP client connections go out from the IP address on the
> DUL. This isn't acceptable because anybody subscribing to the DUL
> will reject his email.
>
> 3) Use a wildcard smtproutes entry to redirect his email to his ISP's
> email relay. This isn't acceptable because he doesn't want to have to
> trust his ISP. He wants to be able to look in his log files and know
> that the email has been accepted by the recipient's SMTP server.
>
> 4) He could change the default route to point to the slow connection.
> Obviously unacceptable.
>
> 5) He simply MUST convince qmail-remote to bind to the IP address of
> the slow non-DUL interface. Unfortunately, there is no way to do that
> short of patching qmail. Why should he have to patch qmail in order
> to add a feature he needs? As you've said yourself, the problem with
> people offering patches is that you don't get an indication of how
> many people are using the patch.
>
> 6) His only acceptable alternative to patching qmail is to try to
> convince you to add this as a feature to qmail. Other people have
> tried to get this feature added, and you've called their desire
> "frivolous". He doesn't hold out much hope for success.
And, of course,
7) Use operating system features to ensure that all outbound traffic to
port 25 goes out the slower interface. This should be trivial with
ipfilter/ipnat, ipfw/natd or the Linux-packet-filter-and-nat of the week,
no?
This does not strike me as too large a hoop to jump through for such a
specialized need, and should work flawlessly once configured.
Not trying to make your point invalid, as I do think that this code, if
reviewed, should be simple enough to integrate in the source. Just
trying to point out another option.
P.S. If inegration is going to happen, I wouldn't mind seeing the
ipme.c/0.0.0.0 patch in place, either. I _know_ the OS is supposed to
DTRT with it, but this wouldn't be the first time Dan has had to work
around a braindead decision by authors of other OSs. :)
--
Greg White
