If the sysadmin knows you're using fetchmail and they're good, they'll let you know if they're going to break your setup. Or they'll warn you they're making an MTA change. Hell, they should be doing that anyway -- system changes should be announced.
Fetchmail does work, and if the system is left alone, won't break.
If you or the sysadmin are changing things, you or the sysadmin are responsible for those changes, including good communication that they're happening and version management control.
You're again blaming someone else for your configuration error again. It's not the sysadmin's fault. You chose fetchmail and configured it. Did you communicate that choice of how you get your mail to the sysadmin? Do they approve of such a configuration.
I don't know of any sysadmins who've made local MTA changes ever that would break fetchmail, but perhaps you have run into it because of lack of communication.
If what you want is "just works - always" then you need your own mail server you control and configure. That's not difficult to get. Dump fetchmail, fire up your MTA of choice and go for it. Then when you have users on your systems someday you can forget to announce an MTA change to them too! ;-)
Nate
Vincent Lefevre wrote:
On 2003-11-05 11:52:37 -0700, Nate Duehr wrote:
It's not nonsense. fetchmail's authors can't be held responsible for you not configuring your MTA correctly. And they certainly shouldn't try to check for every possible MTA configuration under the sun. Maybe you wrote your own MTA? How would they know?
It isn't necessarily a misconfiguration; just rules that will make messages coming from outside the local network disappear, for instance. The user can't always control the administrator's decision. There could also be incorrect bounce detection; in this case, the MTA needs to know that some message comes from fetchmail.
You learn to TEST things like MTA configurations in the Unix environment.
What if the administrator changes the MTA configuration (in general, without warning the user)?
What if the ISP changes the POP3 configuration (in general, without warning the user)?
It's so much more powerful and better when you've actually engineered your solution (engineering includes a test phase, remember) to your specifications than to trust some programming guy you've never met to do all the Right Things.
I don't want something powerful. I want something that works. If I wanted something powerful, I would have used procmail, not the local MTA.
Unix's building-block approach gives you more visibility into the data chain than any monolithic application could ever do, and in the process, gives you bigger responsibility to check each step thouroughly and think about your implementation carefully.
For an operation as simple as a copy, I don't see any problem implementing that in the appplication (in fact, it is implemented in fetchmail, but it is neither the default, nor the recommended way).
I've always prefered things like "cmd < file" to "cat file | cmd" in a shell, though "cat" is more powerful that a simple redirection.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
