Dan, how do we solve this problem?
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. What should he do? Give up on convincing you and patch qmail? -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | 521 Pleasant Valley Rd. | +1 315 268 1925 voice | #exclude Potsdam, NY 13676-3213 | +1 315 268 9201 FAX |
Re: Dan, how do we solve this problem?
Although I'm no expert in qmail (still getting the feet wet here), I am a network engineer. What this individual really should do is go back to their ISP and ask for a fixed IP address that isn't part of a dial-up users group. Trying to run a mail server - ANY mail server - over a dialup IP is certain to lead to headaches. There are, however, other problems to consider. Many mail servers do a reverse-DNS lookup to verify that the mail is coming from an address that is a valid MX record. Without a fixed IP address to bind to an MX record, this mail sysop is headed for additional troubles. -Steve > 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. > > What should he do? Give up on convincing you and patch qmail? > > -- > -russ nelson <[EMAIL PROTECTED]> http://russnelson.com > Crynwr sells support for free software | PGPok | > 521 Pleasant Valley Rd. | +1 315 268 1925 voice | #exclude > Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | >
Re: Dan, how do we solve this problem?
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
Re: Dan, how do we solve this problem?
After reading some initial responses to this, I thought it was worth asking for clarification: (4) and (5) together would indicate that the user wants to use his "ownership" of the slow connection's IP address as a source for the mail, but wants to deliver it via tha fast DUL-listed connection. Is that the problem we're addressing? If not, please disregard the babble below. If so, it seems that any solution allowing this will cause problems (in this particular case, anyway) at the point his upstream ISP (on the fast side) checks that the packets coming down the pipe are from a valid IP address (i.e. one that is supposed to be located on that side of that pipe). Anything less secure would seem to encourage IP spoofing. On a less technical note, it seems that addressing the state of being listed in a DUL by patching/modifying/changing software won't ever scale well. The purpose of blocking lists and their use by ISPs is to actively and immediately discourage mail abuse AND to make end-users aware of what their ISPs are facilitating. Without knowing all the circumstances involved, I think the user should take (1) a little farther; just because he/she doesn't have a fixed IP doesn't mean that he/she can't pursue the issue with the ISP. It's true that they may be unable to respond adequately, but making some noise about the issue seems like a lower risk than, well, asking Dan to add a feature to qmail. :) Chris On Sun, 5 Aug 2001, 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. > > What should he do? Give up on convincing you and patch qmail? > > -- Chris Hardie - - mailto:[EMAIL PROTECTED] -- http://www.summersault.com/chris/ --
Re: Dan, how do we solve this problem?
Chris Hardie writes: > > After reading some initial responses to this, I thought it was worth > asking for clarification: (4) and (5) together would indicate that the > user wants to use his "ownership" of the slow connection's IP address as a > source for the mail, but wants to deliver it via tha fast DUL-listed > connection. Is that the problem we're addressing? Well, on one level he just wants it to work, but on another level he would like to be able to tell qmail to use the slow static IP connection. On the one hand, as Greg says, he can use operating system facilities, but on the other hand, bind() exists to solve the problem, except that qmail-remote won't do a bind() without patching. -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | 521 Pleasant Valley Rd. | +1 315 268 1925 voice | All extremists should Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | be shot.
