Nice cop out. Fetchmail is a hybrid MTA+MUA. Since it straddles the
line, it should follow the rules of least surprise, namely:
1. don't delete a messages without knowing they can be / are
delivered successfully
2. make sure error messages that come from temporary config
issues are sent to the person who can fix them.
FYI, it's easy to fix, just use the correct ordering of download, transmit,
delete that sendmail and other MTAs use. Sendmail doesn't delete a message
out of its spool just because it was sent to the next MTA in the chain,
instead it *waits* for the next MTA to acknowledge the successful receipt
of the message. Funnily, it even fsync()s the spool before acknowledging
incoming messages.
> If you have some magic patch to fix this, I'll take it. If you have
> nothing constructive to contribute, please take your venom elsewhere.
Eric, you're asking kernel developers to trust that you are dealing with
the design issues correctly. Part of that means understanding where the
priorities of the issues that concern you fit in with the rest of the
project. That means understanding what current practice is, and what it
will be to all the players involved (core kernel developers, bleeding edge
users, end users who want a stable system, distro users, distro developers).
So far, I see proof that you are not good at understanding design issues
that don't interest you. This flame war is proof that you're very out of
sync with the rest of the developers. I'm asking you to show some goodwill
by going back and fixing the design issues in your own project in order
to better understand some of the currents at work. Until then, I won't
use fetchmail, and I pity the poor users that do.
-ben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/