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.