[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The Unix Philosophy (was Re: POP3 mail fetcher that supports unreliable connections?)

Sounds like what you want is better communication with your sysadmin?

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! ;-)


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

You learn to TEST things like MTA configurations in the Unix

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

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

I've always prefered things like "cmd < file" to "cat file | cmd"
in a shell, though "cat" is more powerful that a simple redirection.

Reply to: