fetchmail-users

[fetchmail-users] fetchmail 6.3.4 stable release

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greetings,

I am announcing the release of fetchmail 6.3.4. This new stable version
of fetchmail fixes several minor bugs, adds a --pidfile option, a
Vietnamese translation and updates other translations.
For details, please see below.

The software is available from:
<http://developer.berlios.de/project/showfiles.php?group_id=1824&release_id=9751>

The fetchmail home pages is:
<http://www.fetchmail.info/>  or  <http://fetchmail.berlios.de/>

These are the relevant changes in 6.3.4 since 6.3.3;
unless otherwise noted, changes to this release were made by Matthias Andree:

# DEPRECATED FEATURES AND MAJOR INCOMPATIBLE CHANGE ADVANCE WARNINGS
* The MX and host alias DNS lookups that fetchmail performs in multidrop mode
  are obsolete, deprecated and may be removed from a future fetchmail version.
  They have never supported IPv6 (including IPv6-mapped IPv4) anyhow.
* The monitor and interface options may be removed from a future fetchmail
  version as they are not sufficiently portable.
* POP2 is obsolete.
  Support for POP2 may be removed from a future fetchmail version.
* RPOP is obsolete, support may be removed from a future fetchmail release.
* --sslcertck may become a default setting in a future fetchmail version.
* The multidrop To/Cc guessing code along with the fragile duplicate suppressor
  is deprecated and may be removed from a future release.
* The --enable-fallback (fall back to MDA if MTA unavailable) may be removed
  from a future fetchmail release.
* The "protocol auto" default inside fetchmail may be removed from a future
  fetchmail release. Explicit configuration of the protocol is recommended.

# KNOWN BUGS AND WORKAROUNDS:
  (this section floats upwards through the NEWS to be on top of the list)
* fetchmail does not handle messages without Message-ID header well
  (See sourceforge.net bug #780933)
* Sun Workshop 6 (SPARC) is known to miscompile the lexer in 64-bit mode.
  Either compile 32-bit code or use GCC to compile 64-bit fetchmail.
  Note that fetchmail doesn't take advantage of 64-bit code anyways,
  so compiling 32-bit SPARC code should be fine.
* The code still isn't 100% ISO-C compliant, some configurations attempt to
  compile files that are empty after preprocessing, which can cause compiler
  diagnostics and perhaps jam the compilation on strict compilers.

# BUG FIXES:
* configure: detect res_* functions properly with newer glibc ABIs.
  Patch by Miloslav Trmac.
* tracepolls: add folder information if available. Reported by Terry Brown.
* lexer: add %option noyywrap to avoid link errors about missing yywrap().
* a few more type fixes for report/snprintf, patch by Miloslav Trmac.
* bouncing: fetchmail would still send "General SMTP/ESMTP error." bounces
  in spite of "no bouncemail" configuration.
* SSL/TLS: if, for a certain server, an sslfingerprint is specified and
  sslcertck is NOT set, suppress printing SSL certificate mismatch errors.
  (Reported by Hannes Erven.)
* SSL/TLS: always print if the sslfingerprint mismatches, even in silent
  mode.  (This is for consistency with certificate verification errors.)

# TRANSLATION UPDATES:
* German/de (Matthias Andree), French/fr (Matthias Andree), Spanish/es (Héctor
  García), Polish/pl (Jakub Bogusz), Japanese/ja (Takeshi Hamasaki)
* New Vietnamese/vi translation (Clytie Siddall).
* Updated French descriptions for the .spec file (Stéphane Schildknecht,
  Luc Pionchon, Matthias Andree).

# CHANGES:
* pidfile: there is a new command-line (--pidfile PATH) and global option for
  the rcfile (set pidfile [=] "/path/to/pidfile") option to allow overriding
  the default location of the PID file.
  Requested by Héctor García, Debian maintainer.
* specgen.sh: Converted to UTF-8 to support translated texts better.

Regards,

- -- 
Matthias Andree
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFEP9NcvmGDOQUufZURArqIAKC6oo1DQLVwV9Luct07Q1AiCY7SvACg0VPL
fErfpBSuF828FlAI8payL+A=
=uWqI
-----END PGP SIGNATURE-----

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

[Dale P. <po...@ki...>]

Hello,
I realize that you hate multidrop, and generally disparage and deprecate 
the heck out of it, but for some of us, it's about the only way to make 
our email come out halfway decent. Given the text of this announcement, 
I need to ask some questions, and also see if I'm going to have to 
squirrel away a "last usable" copy of fetchmail source at some point.

Matthias Andree wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Greetings,
>
> I am announcing the release of fetchmail 6.3.4. This new stable version
> of fetchmail fixes several minor bugs, adds a --pidfile option, a
> Vietnamese translation and updates other translations.
> For details, please see below.
>
> The software is available from:
> <http://developer.berlios.de/project/showfiles.php?group_id=1824&release_id=9751>
>
> The fetchmail home pages is:
> <http://www.fetchmail.info/>  or  <http://fetchmail.berlios.de/>
>
> These are the relevant changes in 6.3.4 since 6.3.3;
> unless otherwise noted, changes to this release were made by Matthias Andree:
>
> # DEPRECATED FEATURES AND MAJOR INCOMPATIBLE CHANGE ADVANCE WARNINGS
> * The MX and host alias DNS lookups that fetchmail performs in multidrop mode
>   are obsolete, deprecated and may be removed from a future fetchmail version.
>   They have never supported IPv6 (including IPv6-mapped IPv4) anyhow.
>   
Is this the 'aka' being deprecated, or is it some implicit lookup that I 
won't have to worry about, as long as I have 'aka' properly set up?
> * The monitor and interface options may be removed from a future fetchmail
>   version as they are not sufficiently portable.
> * POP2 is obsolete.
>   Support for POP2 may be removed from a future fetchmail version.
> * RPOP is obsolete, support may be removed from a future fetchmail release.
> * --sslcertck may become a default setting in a future fetchmail version.
> * The multidrop To/Cc guessing code along with the fragile duplicate suppressor
>   is deprecated and may be removed from a future release.
>   
Related to the 'aka' question, I noticed that when I upgraded to 6.3.2, 
multidrop pretty much fell apart for me, delivering all mail to the 
default id. I went back and RTFM, ran fetchmail with extra '-v's, added 
some extra 'aka's, and actually got it running better than ever. Most 
notably, we'd always lived with some duplicates that were now resolved 
and eliminated. Given that I've already spent the effort to adapt to the 
jump from 6.2.x to 6.3.2, am I set for the foreseeable future, or do 
these notes presage major pain to come?
> * The --enable-fallback (fall back to MDA if MTA unavailable) may be removed
>   from a future fetchmail release.
> * The "protocol auto" default inside fetchmail may be removed from a future
>   fetchmail release. Explicit configuration of the protocol is recommended.
>
> # KNOWN BUGS AND WORKAROUNDS:
>   (this section floats upwards through the NEWS to be on top of the list)
> * fetchmail does not handle messages without Message-ID header well
>   (See sourceforge.net bug #780933)
> * Sun Workshop 6 (SPARC) is known to miscompile the lexer in 64-bit mode.
>   Either compile 32-bit code or use GCC to compile 64-bit fetchmail.
>   Note that fetchmail doesn't take advantage of 64-bit code anyways,
>   so compiling 32-bit SPARC code should be fine.
> * The code still isn't 100% ISO-C compliant, some configurations attempt to
>   compile files that are empty after preprocessing, which can cause compiler
>   diagnostics and perhaps jam the compilation on strict compilers.
>
> # BUG FIXES:
> * configure: detect res_* functions properly with newer glibc ABIs.
>   Patch by Miloslav Trmac.
> * tracepolls: add folder information if available. Reported by Terry Brown.
> * lexer: add %option noyywrap to avoid link errors about missing yywrap().
> * a few more type fixes for report/snprintf, patch by Miloslav Trmac.
> * bouncing: fetchmail would still send "General SMTP/ESMTP error." bounces
>   in spite of "no bouncemail" configuration.
> * SSL/TLS: if, for a certain server, an sslfingerprint is specified and
>   sslcertck is NOT set, suppress printing SSL certificate mismatch errors.
>   (Reported by Hannes Erven.)
> * SSL/TLS: always print if the sslfingerprint mismatches, even in silent
>   mode.  (This is for consistency with certificate verification errors.)
>   
I only WISH my ISP would support ssl/tls, or etrn, or odmr. I'm STUCK 
with multidrop, unless I spring for more $$$ to use a different provider 
for my email. I'm already paying $$$$ for a cable ISP and $$ for my 
domain and forwarding, not to mention $$.$e$$ for kids' education, so 
$$$ just to avoid multidrop just isn't in the cards, for now. (My ISP 
has multiple POP boxes, but my domain forwarding doesn't have enough 
capability, so I use multidrop.)

Dale Pontius
> # TRANSLATION UPDATES:
> * German/de (Matthias Andree), French/fr (Matthias Andree), Spanish/es (Héctor
>   García), Polish/pl (Jakub Bogusz), Japanese/ja (Takeshi Hamasaki)
> * New Vietnamese/vi translation (Clytie Siddall).
> * Updated French descriptions for the .spec file (Stéphane Schildknecht,
>   Luc Pionchon, Matthias Andree).
>
> # CHANGES:
> * pidfile: there is a new command-line (--pidfile PATH) and global option for
>   the rcfile (set pidfile [=] "/path/to/pidfile") option to allow overriding
>   the default location of the PID file.
>   Requested by Héctor García, Debian maintainer.
> * specgen.sh: Converted to UTF-8 to support translated texts better.
>
> Regards,
>
> - -- 
> Matthias Andree
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.0 (GNU/Linux)
>
> iD8DBQFEP9NcvmGDOQUufZURArqIAKC6oo1DQLVwV9Luct07Q1AiCY7SvACg0VPL
> fErfpBSuF828FlAI8payL+A=
> =uWqI
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Fetchmail-friends mailing list
> Fet...@li...
> http://lists.ccil.org/cgi-bin/mailman/listinfo/fetchmail-friends
>   

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

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

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.

> the heck out of it, but for some of us, it's about the only way to
> make our email come out halfway decent.

Certainly not. Maildrop is, in many cases, a better alternative to
procmail and more than just a surrogate, and I have yet to see a
reasonable procmail construct that you can't write in maildrop or that
would look uglier.

I'll concede I'm biased WRT maildrop's syntax which borrows a bit from
C/C++/Java, but the other reasons like error handling are so much better
in maildrop it's worth a look. Even if your .procmailrc has two dozen
rules, it's worth the switch.

> Given the text of this announcement, I need to ask some questions, and
> also see if I'm going to have to squirrel away a "last usable" copy of
> fetchmail source at some point.

It's not that fetchmail would stop working with procmail, or something
else, but rather that I'm not going to help you with getting procmail to
work with fetchmail and vice versa. I don't intend to waste my time
helping people to shoot themselves in their feet.

>> # DEPRECATED FEATURES AND MAJOR INCOMPATIBLE CHANGE ADVANCE WARNINGS
>> * The MX and host alias DNS lookups that fetchmail performs in multidrop mode
>>   are obsolete, deprecated and may be removed from a future fetchmail version.
>>   They have never supported IPv6 (including IPv6-mapped IPv4) anyhow.

> Is this the 'aka' being deprecated, or is it some implicit lookup that I
> won't have to worry about, as long as I have 'aka' properly set up?

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.

> Related to the 'aka' question, I noticed that when I upgraded to 6.3.2,
> multidrop pretty much fell apart for me, delivering all mail to the
> default id. I went back and RTFM, ran fetchmail with extra '-v's, added
> some extra 'aka's, and actually got it running better than ever.

Well, that is, in fact, the reason why the automatisms will go and users
will have to use "aka" and thereabouts after 6.4.0.

It's not like a hundred of aliased domains were changing every day, so
"aka" will work well enough for most.

> Most notably, we'd always lived with some duplicates that were now
> resolved and eliminated. Given that I've already spent the effort to
> adapt to the jump from 6.2.x to 6.3.2, am I set for the foreseeable
> future, or do these notes presage major pain to come?

The exact effect will, of course, depend on configuration. Assuming the
"aka" configuration covers all the destination addresses, that part
would very likely be set.

The announcements are mainly there so people who intend to upgrade from
6.3.X to a newer 6.4, 6.Y, 7.0, ... release know where to look before
actually installing the newer version. My idea is letting users make an
/informed/ decision. No more luring people into "gold" versions with
radical changes.

I will keep an eye on compatibility in configuration where that is
feasible and sensible. But do you know anyone who's using POP2 to fetch
mail? I don't. Do you know any ISP where the MX is the POP3 server so
that implicit DNS lookups to detect domain aliases actually work? None
of mine does.

> I only WISH my ISP would support ssl/tls, or etrn, or odmr. I'm STUCK
> with multidrop, unless I spring for more $$$ to use a different provider
> for my email. I'm already paying $$$$ for a cable ISP and $$ for my
> domain and forwarding, not to mention $$.$e$$ for kids' education, so
> $$$ just to avoid multidrop just isn't in the cards, for now. (My ISP
> has multiple POP boxes, but my domain forwarding doesn't have enough
> capability, so I use multidrop.)

Well, multidrop can work if done right. See
<http://home.pages.de/~mandree/mail/multidrop> - if the requirements
listed there are met, multidrop will work reliably, without any
duplicate/undeliverable messages (except those with mistyped or guessed
addresses, think spammers trying a dictionary of local addresses on your
*@your.example.org catchall multidrop).

As long as hashed authentication schemes such as CRAM-MD5 or APOP are
supported by your ISP, SSL/TLS is not actually needed, because the mail
has arrived at your provider's site unencrypted anyways and
APOP/CRAM-MD5 still protect your password from eavesdropping, and for
encrypted mail, there are GnuPG and S/MIME which don't require ISP
support, consent or something like that. And with Thunderbird with the
Enigmail extension, GnuPG is simple enough to use, too -- IMO.

All in all, there will not be much to worry about that would make
fetchmail unusable.

-- 
Matthias Andree

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

[Dale P. <po...@ki...>]

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. 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.

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...
>   
>> the heck out of it, but for some of us, it's about the only way to
>> make our email come out halfway decent.
>>     
>
> Certainly not. Maildrop is, in many cases, a better alternative to
> procmail and more than just a surrogate, and I have yet to see a
> reasonable procmail construct that you can't write in maildrop or that
> would look uglier.
>
> I'll concede I'm biased WRT maildrop's syntax which borrows a bit from
> C/C++/Java, but the other reasons like error handling are so much better
> in maildrop it's worth a look. Even if your .procmailrc has two dozen
> rules, it's worth the switch.
>
>   
>> Given the text of this announcement, I need to ask some questions, and
>> also see if I'm going to have to squirrel away a "last usable" copy of
>> fetchmail source at some point.
>>     
>
> It's not that fetchmail would stop working with procmail, or something
> else, but rather that I'm not going to help you with getting procmail to
> work with fetchmail and vice versa. I don't intend to waste my time
> helping people to shoot themselves in their feet.
>   
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.
>   
>>> # DEPRECATED FEATURES AND MAJOR INCOMPATIBLE CHANGE ADVANCE WARNINGS
>>> * The MX and host alias DNS lookups that fetchmail performs in multidrop mode
>>>   are obsolete, deprecated and may be removed from a future fetchmail version.
>>>   They have never supported IPv6 (including IPv6-mapped IPv4) anyhow.
>>>       
>
>   
>> Is this the 'aka' being deprecated, or is it some implicit lookup that I
>> won't have to worry about, as long as I have 'aka' properly set up?
>>     
>
> 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. 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.

Thanks,
Dale Pontius
>   
>> Related to the 'aka' question, I noticed that when I upgraded to 6.3.2,
>> multidrop pretty much fell apart for me, delivering all mail to the
>> default id. I went back and RTFM, ran fetchmail with extra '-v's, added
>> some extra 'aka's, and actually got it running better than ever.
>>     
>
> Well, that is, in fact, the reason why the automatisms will go and users
> will have to use "aka" and thereabouts after 6.4.0.
>
> It's not like a hundred of aliased domains were changing every day, so
> "aka" will work well enough for most.
>
>   
>> Most notably, we'd always lived with some duplicates that were now
>> resolved and eliminated. Given that I've already spent the effort to
>> adapt to the jump from 6.2.x to 6.3.2, am I set for the foreseeable
>> future, or do these notes presage major pain to come?
>>     
>
> The exact effect will, of course, depend on configuration. Assuming the
> "aka" configuration covers all the destination addresses, that part
> would very likely be set.
>
> The announcements are mainly there so people who intend to upgrade from
> 6.3.X to a newer 6.4, 6.Y, 7.0, ... release know where to look before
> actually installing the newer version. My idea is letting users make an
> /informed/ decision. No more luring people into "gold" versions with
> radical changes.
>
> I will keep an eye on compatibility in configuration where that is
> feasible and sensible. But do you know anyone who's using POP2 to fetch
> mail? I don't. Do you know any ISP where the MX is the POP3 server so
> that implicit DNS lookups to detect domain aliases actually work? None
> of mine does.
>
>   
>> I only WISH my ISP would support ssl/tls, or etrn, or odmr. I'm STUCK
>> with multidrop, unless I spring for more $$$ to use a different provider
>> for my email. I'm already paying $$$$ for a cable ISP and $$ for my
>> domain and forwarding, not to mention $$.$e$$ for kids' education, so
>> $$$ just to avoid multidrop just isn't in the cards, for now. (My ISP
>> has multiple POP boxes, but my domain forwarding doesn't have enough
>> capability, so I use multidrop.)
>>     
>
> Well, multidrop can work if done right. See
> <http://home.pages.de/~mandree/mail/multidrop> - if the requirements
> listed there are met, multidrop will work reliably, without any
> duplicate/undeliverable messages (except those with mistyped or guessed
> addresses, think spammers trying a dictionary of local addresses on your
> *@your.example.org catchall multidrop).
>
> As long as hashed authentication schemes such as CRAM-MD5 or APOP are
> supported by your ISP, SSL/TLS is not actually needed, because the mail
> has arrived at your provider's site unencrypted anyways and
> APOP/CRAM-MD5 still protect your password from eavesdropping, and for
> encrypted mail, there are GnuPG and S/MIME which don't require ISP
> support, consent or something like that. And with Thunderbird with the
> Enigmail extension, GnuPG is simple enough to use, too -- IMO.
>
> All in all, there will not be much to worry about that would make
> fetchmail unusable.
>
>   

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

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

[Rob M. <rob...@gm...>]

On 4/17/06, Dale Pontius <po...@ki...> wrote:
> Hello,
> I realize that you hate multidrop, and generally disparage and deprecate
> the heck out of it, but for some of us, it's about the only way to make
> our email come out halfway decent. Given the text of this announcement,
> I need to ask some questions, and also see if I'm going to have to
> squirrel away a "last usable" copy of fetchmail source at some point.

It's also pretty much my only option (and if I switch hosts as I plan,
it will be my only option), so I'm in favour of a solid multidrop. 
The problem has, IMO, been that historically much of the multidrop
stuff has been based around guesswork and has often given different
results from what was intended or expected.

Just take a look through the archive of the old list and you'll see :-)

> I only WISH my ISP would support ssl/tls, or etrn, or odmr. I'm STUCK
> with multidrop, unless I spring for more $$$ to use a different provider
> for my email. I'm already paying $$$$ for a cable ISP and $$ for my
> domain and forwarding, not to mention $$.$e$$ for kids' education, so
> $$$ just to avoid multidrop just isn't in the cards, for now. (My ISP
> has multiple POP boxes, but my domain forwarding doesn't have enough
> capability, so I use multidrop.)

Actually, I'm looking at switching from a provider that, in theory,
allows me to avoid the use of multidrop to one that would force this. 
I'm planning this because my current provider is, well, less than
brilliant :)  I've got a vested interest in multidrop staying.

However, I don't believe that there is any intention of removing
multidrop.  From my understanding the intention is to fix the parts
that are broken (or remove the parts that should never have been
there).

Of course, Matthias may come along and say I'm wrong, but I'm hoping not :-)

--
                 Please keep list traffic on the list.
Rob MacGregor
      Whoever fights monsters should see to it that in the process he
        doesn't become a monster.                  Friedrich Nietzsche

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

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

"Rob MacGregor" <rob...@gm...> writes:

> However, I don't believe that there is any intention of removing
> multidrop.  From my understanding the intention is to fix the parts
> that are broken (or remove the parts that should never have been
> there).
>
> Of course, Matthias may come along and say I'm wrong, but I'm hoping not :-)

Exactly - my plan is to remove parts that either shouldn't have been
there and/or that were there but have never worked as advertised. But I
think it'll take some time until a new 6.4 or 6.5 release, and in the
meanwhile I'll complain to BerliOS that the

http://prdownload.berlios.de/fetchmail/ 
http://download.berlios.de/fetchmail/ 
http://download2.berlios.de/fetchmail/ 

are no longer browsable - because that used to be the place to get old
versions (and it still is if you add the filename to the URL, for
instance, fetchmail-6.2.5.5.tar.bz2 - not that I'd recommend or support
it, but it's still there and will be).

-- 
Matthias Andree