Repeat after me:
Fetchmail is a transport layer, not an interactive client.
Fetchmail is a transport layer, not an interactive client.
Fetchmail is a transport layer, not an interactive client.
Fetchmail is a transport layer, not an interactive client.
Fetchmail is a transport layer, not an interactive client.
: : : :
Fetchmail is a transport layer, not an interactive client.
In other words, *no*. I will not accept such patches. They would
inevitably followed by more patches for content-based filtering and
all kinds of other crap. That is not what fetchmail is for.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
Eric,
I think this special case of policy is not gearing fetchmail towards becoming
an interactive client. I read the FAQ where the
requested feature is said to be a Outlook Express - like feature. I'm afraid
that this way the request is falsely branded as an
interactive client like feature. Which it is not. If "keep" is not policy and
neither is "no keep", then why is "keep=2 days"? I
place the request in the same basket as the resource limit control options that
allows one to control the smooth working of the
email infrastructure.
As the author of popclean I see myself confronted with the request for IMAP
support. This is sensible and I'm working on it as we
speak. But it is another effort to redo things that fetchmail already does so
well. Now ssl is in I see my option list becoming
dangerously similar to fetchmail's. I like working on it but feel it should
actually be redundant. It's a waste of both machine and
human bandwidth and cpu cycles.
Repeat after me:
Delayed deletion does not make fetchmail an interactive client just because OE
does it.
Delayed deletion does make OE a transport layer because fetchmail should do it.
Sorry for being obnoxious. I can't help myself. I'll get off my soapbox now.
The world is facing more important challenges we must
be concerned with.
Regards,
Jan
http://www.klaverstijn.nl/popclean