Re: [fetchmail-users] Re: [fetchmail]fetchmail 6.3.4 stable release

[Matthias A. <mat...@gm...>]

On Tue, 18 Apr 2006, Dale Pontius wrote:

> Matthias Andree wrote:
> >Dale Pontius <po...@ki...> writes:
> >
> >>Hello,
> >>I realize that you hate multidrop, and generally disparage and deprecate
> >
> >That would be "procmail", and that antipathy is based on technical reasons.
> >
> No, I was talking fetchmail's "multidrop", not maildrop or procmail. As 
> a matter of fact, I AM using procmail, but that's more of an historical 
> accident than preference.

Ah, sorry, missed that in the late evening and misread it as maildrop
(the MDA). My apologies for not reading and thinking more carefully.

I'm not against multidrop as such; but several false decisions have been
made in fetchmail's history that need to be corrected to make fetchmail
reliable, and fetchmail has for far too long deluded users into
believing multidrop were an easy thing that would "just work" with
second-guessing aliases and recipients in place when in fact the
retrieved messages had been long past recovery and fetchmail had been
fighting lost cases rather than telling the user "sorry, pal, this can't
work".

And fetchmail's logging wasn't (and still isn't) sufficient to log all
the relevant data obtained to make fetchmail's decisions traceable,
which makes debugging such automatic setups next to impossible. If DNS
data changes or servers go temporarily out of synch, retracing this
situation in order to answer questions about the past, as in "why did
fetchmail decide this way" are unanswerable. I think such a state is
worse than asking a bit more explicit configuration from the user.

So I'll rather get rid of using information that can change every minute
and is thus hard to trace and replace it by hardcoded configuration
where that is sensible. It's also easier for the user to understand why
fetchmail did things a certain way if it's based on a configuration the
user made.

When I was rather new to fetchmail, my girl-friend had an account with
her own domain and domain forwards (qmail-style) but it took me quite a
while until I got the multidrop working right.

I think fetchmail could also use a revision of its configuration that is
more helpful in terms of guiding the user rather than slaying him with
the vast configuration space that it offers and just a short option
reference. That's nothing that can happen overnight, and if anyone is
willing to help with the documentation job, (s)he'll be more than
welcome.

To/Cc and DNS guessing will be removed and explicit envelope and domain
configuration will become necessary for POP3/IMAP multidrop, but
multidrop in general will remain. I may require explicit
singledrop/multidrop configuration per separate keyword so that
fetchmail can validate the "users [...] here" lists more strictly, if
that is desired.

> When I moved my email over to my new 
> infrastructure, (new server, Postfix instead of Exim, Dovecot instead of 
> UWash IMAP, etc.) I considered replacing procmail with maildrop. I got 
> the definite impression that maildrop is the better tool, but by this 
> time my procmail rules are all working, and I didn't feel like fussing 
> with it. Maybe some time, when I have time, I'll reexamine this issue.

Well, error handling is the point where procmail setups fall short. At
the very least, add

:0e
{ EXITCODE=75 HOST= }

after each delivering recipe to make sure messages remain in the queue
or on the server if there are problems (out of quota, disk full), rather
than having messages misfiled.

> One other reason, now obsolete... For a while I was running procmail 
> under xinetd as an lmtp server. The basic idea was to completely chroot 
> postfix, instead of having to leave the local delivery part un-chrooted. 
> I eventually decided I'd rather have postfix local delivery un-chrooted 
> and running with elevated authority than procmail, even though both try 
> to drop privileges when possible. Now if maildrop had an lmtp mode...

Well, Postfix drops privileges early, so using Postfix and using
procmail WITHOUT set-uid bit set should be pretty safe in terms of
containing possible havoc to a certain user account while keeping the
system (as the basis of everything) out of harm's way.

Of course, if the .procmailrc (or .mailfilter, for that matter) does
stupid things like injecting untrusted data into the shell, there isn't
much Postfix or an LMTP wrapper could do about that.

> As I said, the whole issue is fetchmail's multidrop mode. The rest of 
> your letter has satisfied my concerns quite nicely. It looks like that 
> work I did after the 6.3.2 upgrade was well worth it, and the right 
> thing to do. I'm guessing that when 6.3.4 makes it to Gentoo x86 I'll 
> have no problems with the upgrade.

Well, that is at least my intention for the 6.3.X releases - update from
6.3.X to 6.3.X+N are supposed to be smooth.

> >The implicit automatic DNS lookups. "aka" will continue to work. The
> >implicit lookups assume the POP3 or IMAP server were the same as the
> >SMTP server of the ISP, which is often untrue nowadays.

> Interestingly enough, since I own a domain and have an email forwarding 
> service for all mail to that domain to be sent to my pop box at my ISP, 
> I find that I needed to add 'aka' statements for the domain-host's 
> forwarding machines. That made everything work *perfectly*, which it 
> never had before.

...and which is evidence that fetchmail's assumption that POP3/IMAP
servers are the same as those recorded as MX (SMTP) servers simply
doesn't hold in yet another individual case.

> I suspect you also changed the "-v -v" debugging 
> information some, because this time it was absolutely clear what I 
> needed to do with 'aka' statements to make things work. I don't remember 
> the debugging information being that useful, before.

Well, not something that addressed this particular issue, but there have
been some logging/verbosity fixes which should make "-v", "-vv", "-vvv",
"--silent" smoother than before. fetchmail is a long way from my calling
it thoroughly logging though.

I hope that clears more multidrop concerns up a bit. It pretty much
looks to me like your configuration (based on "aka") will be supported
by future fetchmail versions.

Kind regards,

-- 
Matthias Andree