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