fetchmail-users — User questions and discussion

Re: [Fetchmail-users] Problem using fetchmail with a user

[Gene H. <ghe...@wd...>]

On Friday 17 October 2014 03:55:32 Matthias Andree did opine
And Gene did reply:
> Am 16.10.2014 um 02:40 schrieb Ken Arromdee:
> > I am running Mageia 4.0 which includes fetchmail 6.3.26.  The
> > following is my
> > 
> > entire /etc/fetchmailrc:
> >     set postmaster "arromdee"
> >     set bouncemail
> >     set no spambounce
> >     set softbounce
> >     set properties ""
> >     poll mail.xxxxxx.net with proto POP3
> >     
> >         user 'arromdee' password 'xxxxxxxx' mda "/bin/procmail -d
> >         arromdee"
> > 
> > I want to run fetchmail as a service, for which Mageia supplies a
> > script in /etc/rc.d.  I want it to retrieve the mail from user
> > arromdee on the remote system and deliver it to user arromdee on my
> > local machine.
> > 
> > This /etc/fetchmailrc does work.  However, I want to be able to put
> > the appropriate lines in my user-specific $HOME/.fetchmailrc, not in
> > the global /etc/fetchmailrc.  How can I do this?  It doesn't seem
> > like my user-specific .fetchmailrc is read at all (unless I run
> > fetchmail as myself instead of as root).
> 
> True on many systems.  You absolutely need to make sure that fetchmail
> is being started as "aromdee", not root.  Check if your boot scripts
> support this -- on many systems, they do not.
> 
> You can however configure fetchmail for daemon mode and launch it from
> cron - if it's already running, the second attempt to start it will
> instead wake up the first instance.
> 
> 
> Note that I advise against using procmail.  It has been unmaintained
> for more than a decade and has design flaws that cause apparent mail
> "loss" (which are not loss but in fact a fallback behaviour that
> causes procmail to _misfile_ mail in error situations, and - albeit
> possible - are hard to overcome by procmail recipes).
> 
Humm, since I have been using procmail for about a decade now, and am 
aware of its unsupported status simply because there have been no updates 
in several years, and it hasn't made any mistakes that I have become aware 
of, what do you suggest as its most painfree replacement?

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

Re: [Fetchmail-users] Problem using fetchmail with a user

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

Am 16.10.2014 um 02:40 schrieb Ken Arromdee:
> I am running Mageia 4.0 which includes fetchmail 6.3.26.  The following is my
> entire /etc/fetchmailrc:
> 
>     set postmaster "arromdee"
>     set bouncemail
>     set no spambounce
>     set softbounce
>     set properties ""
>     poll mail.xxxxxx.net with proto POP3
>         user 'arromdee' password 'xxxxxxxx' mda "/bin/procmail -d arromdee"
> 
> I want to run fetchmail as a service, for which Mageia supplies a script in
> /etc/rc.d.  I want it to retrieve the mail from user arromdee on the remote
> system and deliver it to user arromdee on my local machine.
> 
> This /etc/fetchmailrc does work.  However, I want to be able to put the
> appropriate lines in my user-specific $HOME/.fetchmailrc, not in the global
> /etc/fetchmailrc.  How can I do this?  It doesn't seem like my user-specific
> .fetchmailrc is read at all (unless I run fetchmail as myself instead of as
> root).

True on many systems.  You absolutely need to make sure that fetchmail
is being started as "aromdee", not root.  Check if your boot scripts
support this -- on many systems, they do not.

You can however configure fetchmail for daemon mode and launch it from
cron - if it's already running, the second attempt to start it will
instead wake up the first instance.


Note that I advise against using procmail.  It has been unmaintained for
more than a decade and has design flaws that cause apparent mail "loss"
(which are not loss but in fact a fallback behaviour that causes
procmail to _misfile_ mail in error situations, and - albeit possible -
are hard to overcome by procmail recipes).

[Fetchmail-users] TLS and SSL changes in fetchmail's Git repository

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

Greetings,

I have hacked a bit on the SSL/TLS configuration options in the Git
repository's master branch (that the 7.0.0-alpha previews get snapshot
from).  This is a bleeding-edge preview for skilled users who have
developer toolchains (recent GNU autoconf/automake/gettext, C99 or C++
compiler, git, openssl) installed and are comfortable with trying out
bleeding edge versions and providing technical feedback and can get the
usual quirks solved.

Note: I will not educate users on how this all works - this is an early
preview, we will have formal -alpha snapshots as tarballs later on in
the process, once things stabilize a bit and I have addressed some of
the FIXME's in code.  Contribution welcome, and to be discussed on the
fetchmail-devel@ mailing list.

I have also made my life easy and now the fetchmail 7.0.0-development
branch requires that OpenSSL 1.0.1 be used so that TLS v1.2 is
available.  Ubuntu 12.04LTS, Fedora 20, FreeBSD 9.3 are fine, Ubuntu
10.04LTS is too old.


Changes are:

SSL/TLS options are changed in incompatible ways (names changed,
semantics changed). They are now more independent of one another. The
configuration of the SSL/TLS protocol version no longer implies wrapped
versus STARTTLS mode, so you can now combine STARTTLS with SSLv3, or,
more importantly, TLSv1 or newer with SSL-wrapped mode.  Omitting the
sslproto should now do the right thing by default.

There is a new --sslmode option to pick the mode.

sslcertck is now on by default.

SSLv2 is now forbidden altogether, with no way for users to enable it in
fetchmail.

SSLv3 is now forbidden by default, meaning fetchmail will not
automatically negotiate SSLv3, unless the user explicitly forces it with
the (revised) --sslprotocolversion SSLv3 option.

I should also like to disable TLSv1 and require 1.1+ be used, but that
would seem to be premature and lock out too many sites.

fetchmail's cipher lists can be configured through an environment
variable (for now, meant to become a formal option later on), so for
instance,

env FETCHMAIL_SSL_CIPHERS='ALL:!EXPORT:!LOW:+RC4:@STRENGTH' \
  fetchmail -vv --other --options

If you want to tighten this up a bit more and can get away without RC4
and all your upstream servers permit TLSv1.2, you may want to try this
instead:

env FETCHMAIL_SSL_CIPHERS='ALL:!EXPORT:!LOW:!MEDIUM:@STRENGTH' \
  fetchmail -vv --sslprotocolversion TLSv1.2 --other --options

For me, half of the sites can no longer be polled with these options
(for instance, Microsoft's freemailers no longer work).


If this all seems worth the hassle, I have two Git repositories on
public sites, you can pick either one to clone from:

https://gitorious.org/fetchmail
(Norway)

http://sourceforge.net/p/fetchmail/git/ci/master/tree/
(USA)

Both contain the same data, so pick the one you're more comfortable with.

Quickstart to try fetchmail from Git (I do not offer support for this,
but I'm happy to receive your feedback, or answer questions that give a
strong hint that you are in fact a programmer):

- install requisites (you must find the packages out by yourself,
  I do NOT support this)
- git clone from one of the two Git repositories
- run: git checkout master  # the default checkout goes onto legacy_63
- run: autoreconf -isvf
- mkdir build && cd build && ../configure -C && make check
- in doubt, make sure you use GNU make for the build
  (called gmake on some systems)
  Some of the auto-maintenance in automake output does not work on
  non-GNU make implementations.

The output will then be in build/fetchmail.

[Fetchmail-users] Problem using fetchmail with a user

[<arr...@ra...>]

I am running Mageia 4.0 which includes fetchmail 6.3.26.  The following is my
entire /etc/fetchmailrc:

    set postmaster "arromdee"
    set bouncemail
    set no spambounce
    set softbounce
    set properties ""
    poll mail.xxxxxx.net with proto POP3
        user 'arromdee' password 'xxxxxxxx' mda "/bin/procmail -d arromdee"

I want to run fetchmail as a service, for which Mageia supplies a script in
/etc/rc.d.  I want it to retrieve the mail from user arromdee on the remote
system and deliver it to user arromdee on my local machine.

This /etc/fetchmailrc does work.  However, I want to be able to put the
appropriate lines in my user-specific $HOME/.fetchmailrc, not in the global
/etc/fetchmailrc.  How can I do this?  It doesn't seem like my user-specific
.fetchmailrc is read at all (unless I run fetchmail as myself instead of as
root).

Re: [Fetchmail-users] Relay to Postfix on port 587

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

Am 13.10.2014 um 20:22 schrieb Grant Edwards:
> In gmane.mail.fetchmail.user, you wrote:
> 
>> I need to have fetchmail relay mail to my MTA, Postfix, on port 587. It will
>> also need to authenticate itself like all of my internal users do, How can I
>> accomplish this?
> 
> Fetchmail expects to use an MDA for this.  I use msmtp.
> 
> Check out the "mda" configuration keywoard.
> 

It seems that using an MDA for feeding into an MTA subverts the purpose,
and is way overengineered given Jerry's made it difficult for himself.
Further complicating matters isn't what I'd propose. See other postings
on the list.

Re: [Fetchmail-users] Relay to Postfix on port 587

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

Am 14.10.2014 um 11:02 schrieb Jerry:
> On Mon, 13 Oct 2014 18:55:49 +0200, Matthias Andree stated:
> 
>> Am 13. Oktober 2014 13:00:27 MESZ, schrieb Jerry <je...@se...>:
>>> I need to have fetchmail relay mail to my MTA, Postfix, on port 587. It
>>> will
>>> also need to authenticate itself like all of my internal users do, How
>>> can I
>>> accomplish this?
>>>
>>> This is an example of a typical line in the "fetchmailrc" file.
>>>
>>> poll pop.gmail.com with proto POP3 service 995 timeout 30 envelope
>>> 'Delivered-To' localdomains MyDomain.net bad-header accept
>>> user 'us...@gm...' there with password 'SECRET' options forcecr
>>> dropdelivered smtpname 'us...@My...' ssl sslfingerprint
>>> 'BA:21:62:BD:13:ED:4C:5C:BA:3E:82:D5:19:C0:D1:A5'
>>>
>>> There are over twenty mailboxes checked. Final delivery is via Postfix
>>> to
>>> Dovcote. Dovecote sorts them out using a "sieve" filter.
>>
>> I am sorry to say that the code for what you need (TLS on the SMTP side)
>> has not been written yet. 
> 
> That is what I thought. I don't suppose that you are planning on writing
> that code anytime soon either.

Plans and real life are quite distinct notions.

Fetchmail is a spare-time after-work project that isn't supported by an
organization, if you leave out sf.net hosting services, with practically
no contribution other than my financing the domain and doing the little
work I currently have time for.  (It's not the only FrOSS project I am on.)

I've also gotten used to your expectations more in line with what you
could expect from paid services, so I'll turn a blind eye on that
distraction and move on, to remain on the constructive side of things.

> I am using Postfix with Postscreen. Postfix recommends that when using
> Postscreen, all local injection of mail be via port 587 to bypass the
> screening process.

Then it is in your power to do something about your implementation.  You
can, for instance, use a separate port on Postfix that is configured
similarly to port 587, but that does not require TLS nor authentication,
and that only listens on the loopback interface.

It's more or less a copy of the port 587 service in Postfix's master.cf
with a few lines stripped out or tweaked.

Re: [Fetchmail-users] Relay to Postfix on port 587

[Jerry <je...@se...>]

On Mon, 13 Oct 2014 18:55:49 +0200, Matthias Andree stated:

> Am 13. Oktober 2014 13:00:27 MESZ, schrieb Jerry <je...@se...>:
> >I need to have fetchmail relay mail to my MTA, Postfix, on port 587. It
> >will
> >also need to authenticate itself like all of my internal users do, How
> >can I
> >accomplish this?
> >
> >This is an example of a typical line in the "fetchmailrc" file.
> >
> >poll pop.gmail.com with proto POP3 service 995 timeout 30 envelope
> >'Delivered-To' localdomains MyDomain.net bad-header accept
> >user 'us...@gm...' there with password 'SECRET' options forcecr
> >dropdelivered smtpname 'us...@My...' ssl sslfingerprint
> >'BA:21:62:BD:13:ED:4C:5C:BA:3E:82:D5:19:C0:D1:A5'
> >
> >There are over twenty mailboxes checked. Final delivery is via Postfix
> >to
> >Dovcote. Dovecote sorts them out using a "sieve" filter.
> 
> I am sorry to say that the code for what you need (TLS on the SMTP side)
> has not been written yet. 

That is what I thought. I don't suppose that you are planning on writing
that code anytime soon either.

I am using Postfix with Postscreen. Postfix recommends that when using
Postscreen, all local injection of mail be via port 587 to bypass the
screening process.

-- 
Jerry

Re: [Fetchmail-users] Relay to Postfix on port 587

[jdebert <jd...@ga...>]

On Mon, 13 Oct 2014 07:00:27 -0400
Jerry <je...@se...> wrote:

> I need to have fetchmail relay mail to my MTA, Postfix, on port 587.
> It will also need to authenticate itself like all of my internal
> users do, How can I accomplish this?
> 

This seems to be doing things the hard way. Is there something that
makes this better than simply submitting the usual way using port 25?

jd

Re: [Fetchmail-users] Relay to Postfix on port 587

[Grant E. <gra...@gm...>]

In gmane.mail.fetchmail.user, you wrote:

> I need to have fetchmail relay mail to my MTA, Postfix, on port 587. It will
> also need to authenticate itself like all of my internal users do, How can I
> accomplish this?

Fetchmail expects to use an MDA for this.  I use msmtp.

Check out the "mda" configuration keywoard.

-- 
Grant

Re: [Fetchmail-users] Relay to Postfix on port 587

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

Am 13. Oktober 2014 13:00:27 MESZ, schrieb Jerry <je...@se...>:
>I need to have fetchmail relay mail to my MTA, Postfix, on port 587. It
>will
>also need to authenticate itself like all of my internal users do, How
>can I
>accomplish this?
>
>This is an example of a typical line in the "fetchmailrc" file.
>
>poll pop.gmail.com with proto POP3 service 995 timeout 30 envelope
>'Delivered-To' localdomains MyDomain.net bad-header accept
>user 'us...@gm...' there with password 'SECRET' options forcecr
>dropdelivered smtpname 'us...@My...' ssl sslfingerprint
>'BA:21:62:BD:13:ED:4C:5C:BA:3E:82:D5:19:C0:D1:A5'
>
>There are over twenty mailboxes checked. Final delivery is via Postfix
>to
>Dovcote. Dovecote sorts them out using a "sieve" filter.
>
>Thanks!
>
>-- 
>Jerry
>
>------------------------------------------------------------------------------
>Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS
>Reports
>Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>http://p.sf.net/sfu/Zoho
>_______________________________________________
>Fetchmail-users mailing list
>Fet...@li...
>https://lists.sourceforge.net/lists/listinfo/fetchmail-users

Jerry,

I am sorry to say that the code for what you need (TLS on the SMTP side) has not been written yet. 

Best regards, 
Matthias Andree 

[Fetchmail-users] Relay to Postfix on port 587

[Jerry <je...@se...>]

I need to have fetchmail relay mail to my MTA, Postfix, on port 587. It will
also need to authenticate itself like all of my internal users do, How can I
accomplish this?

This is an example of a typical line in the "fetchmailrc" file.

poll pop.gmail.com with proto POP3 service 995 timeout 30 envelope 'Delivered-To' localdomains MyDomain.net bad-header accept
user 'us...@gm...' there with password 'SECRET' options forcecr dropdelivered smtpname 'us...@My...' ssl sslfingerprint 'BA:21:62:BD:13:ED:4C:5C:BA:3E:82:D5:19:C0:D1:A5'

There are over twenty mailboxes checked. Final delivery is via Postfix to
Dovcote. Dovecote sorts them out using a "sieve" filter.

Thanks!

-- 
Jerry

Re: [Fetchmail-users] help with gmx and starttls

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

Am 25.09.2014 um 17:04 schrieb Jerry:

> Something is wrong on your system. If you actually had that parameter in your
> "main.cf", ie, the one Postfix is using, and then ran "postconf -n", this
> error message would have popped up:
> 
> postconf: warning: /usr/local/etc/postfix/main.cf: unused parameter: smtp_tls_sercrity_level=may

Don't jump to conclusions about something being "wrong" on his computer.
 We have not even assessed whether Stefan ran "postconf -n" at all.  The
proposal to run it a valid one, though and I support it.

Re: [Fetchmail-users] help with gmx and starttls

[Jerry <je...@se...>]

On Thu, 25 Sep 2014 12:29:45 +0200, Stefan Liebl stated:

> Am 2014-09-25 11:20, schrieb Jerry:
> > On Sun, 21 Sep 2014 14:25:06 +0200, Stefan Liebl stated:
> > 
> >> So now it work as desiried. Would have been nice, if postfix had given 
> >> an
> >> error message.
> > 
> > What version of Postfix?
> 
> $ postconf mail_version
> mail_version = 2.11.0

Something is wrong on your system. If you actually had that parameter in your
"main.cf", ie, the one Postfix is using, and then ran "postconf -n", this
error message would have popped up:

postconf: warning: /usr/local/etc/postfix/main.cf: unused parameter: smtp_tls_sercrity_level=may

-- 
Jerry

Re: [Fetchmail-users] help with gmx and starttls

[Stefan L. <S....@gm...>]

Am 2014-09-25 11:20, schrieb Jerry:
> On Sun, 21 Sep 2014 14:25:06 +0200, Stefan Liebl stated:
> 
>> So now it work as desiried. Would have been nice, if postfix had given 
>> an
>> error message.
> 
> What version of Postfix?

$ postconf mail_version
mail_version = 2.11.0

Re: [Fetchmail-users] help with gmx and starttls

[Jerry <je...@se...>]

On Sun, 21 Sep 2014 14:25:06 +0200, Stefan Liebl stated:

> So now it work as desiried. Would have been nice, if postfix had given an
> error message.

What version of Postfix?

-- 
Jerry

Re: [Fetchmail-users] help with gmx and starttls

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

Am 21.09.2014 um 14:25 schrieb Stefan Liebl:

> Thanks, so I could find the bug. In /etc/postfix/main.cf I had a typo in the 
> parameter
> smtp_tls_sercrity_level = may
> it has to be
> smtpd_tls_security_level = may
> 
> So now it work as desiried. Would have been nice, if postfix had given an error 
> message.

It can't do that easily because there are some parameters that define
others, so it's not easy for Postfix to tell a typo from a new parameter
that might be defined inside another, and for parameters where smtp and
smtpd are different it can't tell them from one another at all.

The canonical way is to run "postconf -n" and check if Postfix has
picked up your parameter.

Re: [Fetchmail-users] help with gmx and starttls

[Carlos E. R. <car...@op...>]

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

On 2014-09-21 14:25, Stefan Liebl wrote:
> So now it work as desiried. Would have been nice, if postfix had 
> given an error message.

Not with the default log verbosity level. You need data about
connection establishment, I think.

Try:

debug_peer_list = 127.0.0.1

and perhaps:

debug_peer_level = 2

or more.

- -- 
Cheers / Saludos,

		Carlos E. R.
		(from 13.1 x86_64 "Bottle" at Telcontar)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlQex+AACgkQtTMYHG2NR9WuWQCfUsmSTKpdTCk/bKVtX0D6wW8+
cPwAn2C9DlXcTKWBbDfiKA55JKsVQlX2
=6zK3
-----END PGP SIGNATURE-----

Re: [Fetchmail-users] help with gmx and starttls

[Stefan L. <S....@gm...>]

Am Samstag, 20. September 2014, 19:33:19 schrieb Matthias Andree:
> Am 20.09.2014 um 16:34 schrieb Stefan Liebl:
> > I'm just setting up my new server since my old one broke down. I'm stuck
> > at  getting fetchmail to work. I'm getting the following messages in the
> > logfile:
> > 
> > fetchmail[5376]: reading message xx...@gm...@pop.gmx.net:1 of 69 (3255
> > octets) (log message incomplete)
> > fetchmail[5376]: SMTP error: 530 5.7.0 Must issue a STARTTLS command first
> 
> The problem is not the inbound path, but the outbound path ("SMTP").
> 
> Your MTA does not accept mail from localhost through an unencrypted
> connection.  You might consider permitting non-TLS through the loopback
> interface, if someone can sniff that, he can do anything else on your
> computer as well.
> 
> Fetchmail does not currently support TLS-wrapped or STARTTLS on the SMTP
> side.

Thanks, so I could find the bug. In /etc/postfix/main.cf I had a typo in the 
parameter
smtp_tls_sercrity_level = may
it has to be
smtpd_tls_security_level = may

So now it work as desiried. Would have been nice, if postfix had given an error 
message.

Stefan

Re: [Fetchmail-users] help with gmx and starttls

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

Am 20.09.2014 um 16:34 schrieb Stefan Liebl:
> Hi,
> 
> I'm just setting up my new server since my old one broke down. I'm stuck at 
> getting fetchmail to work. I'm getting the following messages in the logfile:
> 
> fetchmail[5376]: reading message xx...@gm...@pop.gmx.net:1 of 69 (3255 octets) 
> (log message incomplete)
> fetchmail[5376]: SMTP error: 530 5.7.0 Must issue a STARTTLS command first

The problem is not the inbound path, but the outbound path ("SMTP").

Your MTA does not accept mail from localhost through an unencrypted
connection.  You might consider permitting non-TLS through the loopback
interface, if someone can sniff that, he can do anything else on your
computer as well.

Fetchmail does not currently support TLS-wrapped or STARTTLS on the SMTP
side.

[Fetchmail-users] help with gmx and starttls

[Stefan L. <S....@gm...>]

Hi,

I'm just setting up my new server since my old one broke down. I'm stuck at 
getting fetchmail to work. I'm getting the following messages in the logfile:

fetchmail[5376]: reading message xx...@gm...@pop.gmx.net:1 of 69 (3255 octets) 
(log message incomplete)
fetchmail[5376]: SMTP error: 530 5.7.0 Must issue a STARTTLS command first

I think I have the same fetchmail configuration as on my last server:

## /etc/fetchmailrc$                                                                                                                                           
set postmaster "stefan"$                                                                                                                                               
set bouncemail$                                                                                                                                                        
set no spambounce$                                                                                                                                                     
set properties ""$                                                                                                                                                     
set syslog$                                                                                                                                                            
set daemon 60
poll pop.gmx.net with protocol pop3
  user 'xx...@gm...' there with password 'xxx' is 'xxx' here options keep ssl
 
I also tried 'sslproto' with tls1, ssl1, ssl23, but it's the same.
Can someone help me to get it running?

Stefan

Re: [Fetchmail-users] Better home for fetchmail than Sourceforge?

[grarpamp <gra...@gm...>]

> Which one in particular do you propose

I guess I was referring to github in the case of "let's just throw
up a git and bug tracker in one place so we have one". They might
have as long a run going forward as SF did, hard to say, I don't
watch that space.

> complete offering [?]

http://en.wikipedia.org/wiki/Comparison_of_open-source_software_hosting_facilities
http://www.dmoz.org/Computers/Open_Source/Project_Hosting/
http://wiki.list.org/display/COM/Mailman+hosting+services

> [do it yourself?]

For mailing lists... you might be able to score a free/cheap
VPS/host/list contract by posting to:

- webhostingtalk.com
- nanog list, etc... places where big/many fetchmail/unix friendly
users might be
- in general, ask around, it's not like fetchmail is big traffic load

For distribution, git, and bug tracking...
- The same VPS/host and other possibilities above
- Tor hidden service, seriously, these services do run there... you
host it locally on your own box, it's free, secure and reliable.
Users need to run the client to get to it, but it's not a big deal.

I wouldn't really recommend google because users will likely end
up needing a google account to actually do things, and google is
hard/evil... with requiring phone numbers, ads/tracking, etc.

Re: [Fetchmail-users] Better home for fetchmail than Sourceforge?

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

Am 15.09.2014 um 18:47 schrieb grarpamp:

> I meant to suggest back then finding a home for the lists that
> ran mailman+pipermail gzip mboxes. Once found, all the past
> archives you hold could be loaded into it. They could also be
> put up as a tarball, optionally updated quarterly or some such
> if no mm+pm host can be found. Even rsync would work.

I would have liked to find a Mailman list hosting service that is
affordable, but everything I found back then was more expensive than
virtual root servers...

sourceforge.net had the additional advantage that I had already set up a
fetchmail project years ago, when I was unhappy about BerliOS support
and SF.net support was responsive back then.

Things changed since then, everyone knows it took several weeks for
SF.net to import the mailing lists, BerliOS shut down, but yet
sourceforge.net allowed some continuity for downloads, website hosting
and, in theory, tickets.

> Github, or a local bugzilla, trac or request tracker would probably
> be better than SF for ticketing. Export and import would be nice.

Github has too unstable and too inconcise a user interface for the
uninitiated.  Too many high-profile features hidden behind an innocuous
icon.  I know my way around the current interface, but I find it too
light for casual users.

> Sourceforge seems to be stuck in the 'first generation' while
> better options have sprung up around them.

Which one in particular do you propose, especially with a reasonable
response time for support and as a complete offering?

I'm happy to consider alternatives, but I'm not too easily satisfied
when the status quo mostly works and is widely known.

[Fetchmail-users] Better home for fetchmail than Sourceforge?

[grarpamp <gra...@gm...>]

On Mon, Sep 15, 2014 at 3:34 AM, Matthias Andree <mat...@gm...> wrote:
>> grarpamp:
>> tickets that I
>> think got destroyed when the ticket system got destroyed/moved, or maybe
>> on this list, or something like that, I don't remember.

> thank you for the reminder.  I downloaded the ticket data from BerliOS
> but have not yet found a way to recreate Sourceforge tickets from them
> authentically, the instructions that were given on sf.net in May were a
> bit vague and not at all turnkey solutions, quite on the contrary.


"
BerliOS is shutting down end of this month, and their mailing list
export is broken, so I may not be able to obtain subscriber rosters in a
timely manner.

I will move downloads to sourceforge.net, but I have not yet decided if
I want to move the mailing lists there because their list archive
interface is awkward to use and inconcise.
"

Yes, SF has a horribly unuseful archive interface. They seem to
use mailman as management frontend, but skip the good pipermail
archiver in deference to their own junk. So when I just now went
looking for pipermail's gzipped mbox text archives of fetchmail lists
to import into mutt to search and begin to use... well, we can't.

I meant to suggest back then finding a home for the lists that
ran mailman+pipermail gzip mboxes. Once found, all the past
archives you hold could be loaded into it. They could also be
put up as a tarball, optionally updated quarterly or some such
if no mm+pm host can be found. Even rsync would work.

Github, or a local bugzilla, trac or request tracker would probably
be better than SF for ticketing. Export and import would be nice.

Sourceforge seems to be stuck in the 'first generation' while
better options have sprung up around them.

Re: [Fetchmail-users] 2 feature requests for 7.x

[Martin K. <mk...@gm...>]

On Mon, 15 Sep 2014, Matthias Andree wrote:
> Am 10.09.2014 um 10:47 schrieb Martin Koeppe:
>
>> IMO all these SSL related options should be server options, not user
>> options, as they apply before any user name is transmitted to the
>> server, so there should be no need have it configured differently for
>> every user. Ok, the server could behave diferently after user logon
>> depending on the previously negotiated connection. But then I could
>> have 2 different poll sections for the same server.
>
> I have always wondered if we should be adding some notion of scope to
> settings, but this would then have to go along with parenthesizing
> (perhaps using curly braces) of some form, perhaps apply defaults ... to
> ... end defaults statements.
>
> Sooner or later I will have to rewrite the bison parser because it
> invariably must leak memory and has some minor quirks, but have not
> decided on a solution.


If you need to / want to do some incompatible changes anyway, why not 
switch to a totally different config file format? The one that 
bind uses (basically C like) would be my favorite. With the C-style 
/* multi-line comments */ the skip keyword isn't needed anymore IMO.
Also powershell comments would be ok: "#" for single line, "<#" start 
comment, and "#>" end comment.

Then a config could look like this:

{
 	server = "pop.example.com"
 	ssl = "none"

 	poll {
 		user = "pop-server-user"
 		pass = "SECRET"
 		sendto = "user@domain.local"
 	}

 	/* nested defaults */
 	{
 		ssl = starttls
 		sendto = "user2@domain.local"
 		poll {
 			user = "user2"
 			pass = "123456"
 			verbose = yes // to debug this particular poll
 		}

 		poll {
 			user = "user3"
 			pass = "7890"
 			keep = yes // overwrite default
 		}
 		// continue nested defaults block
 		keep = no
 		fetchall = yes
 	} // end of nested defaults block
}
{
 	server = "another.server.com"
 	poll {
 		/* ... */
 	}
}

There are 2 types of blocks, default blocks (unnamed above) which can 
be thought as inner tree nodes, and poll blocks (leaf nodes). The 
whole file can be thought of being in a big default block (root node), 
where the compiled-in defaults are listed. No limit for the nesting 
level. Poll blocks must not contain any other blocks. A poll is done 
for each poll block.

No difference between server and user options, as it may be desirable 
to move e.g. the account name used on several servers to a default 
block. The poll block must just have enough options in it and above 
in the tree to do the poll.


A minimal config for only one account could just look like:
poll {
 	server = "servername"
 	user = "user"
 	pass = "*"
 	sendto = "loc@l"
}

Or even like this:

server = "servername"
user = "user"
pass = "*"
/* sometimes the same password is used for several accounts */
sendto = "loc@l"
poll {}


I only use fetchmail for POP3 polls with single-drop. So maybe not all 
of fetchmail's functions can be covered with this. Block names and 
option names can be changed of course. A ";" like in C might be 
appended to each line. Or, as in powershell, is optional, unless you 
want to specify 2 options on one line, where you could delimit both of 
these with a ";". OTOH if there are multi-line values 
(certificates?), then always a terminating ";" might be good, unless 
the block ends anyway.

Just as an idea.

Martin

Re: [Fetchmail-users] 2 feature requests for 7.x

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

Am 10.09.2014 um 10:47 schrieb Martin Koeppe:

> So "sslcertck" and "sslfingerprint" must be repeated over and over. 
> Also if one server doesn't support ssl at all, it's even worse. I 
> can't specify "ssl" in defaults section, because there is no (or at 
> least not to my knowledge) no-ssl keyword, which I could apply to all 
> user accounts on that server. So instead I added "ssl" to every user 
> account on every other server, just because one server doesn't support 
> it. "sslcertck" is the same.

I thought I had checked for missing no-* options but apparently I missed
those.  These might even be 6.3.X stuff depending on how complex the fix
will be in code, I will check that.

> IMO all these SSL related options should be server options, not user 
> options, as they apply before any user name is transmitted to the 
> server, so there should be no need have it configured differently for 
> every user. Ok, the server could behave diferently after user logon 
> depending on the previously negotiated connection. But then I could 
> have 2 different poll sections for the same server.

I have always wondered if we should be adding some notion of scope to
settings, but this would then have to go along with parenthesizing
(perhaps using curly braces) of some form, perhaps apply defaults ... to
... end defaults statements.

Sooner or later I will have to rewrite the bison parser because it
invariably must leak memory and has some minor quirks, but have not
decided on a solution.

Lemon (from sqlite3's author) is one option, going for C++ with
Boost::Spirit that follows a strict full resource tracking through
objects is another, and there are surely more solutions.

This will entail a parser rewrite and might be a good point in time to
specify such extensions.

(Bison recommends to consider garbage collection, but I'm not sure that
it's the right approach, it can lead to apparently nondeterministic
timing behaviour.)

Thanks for your suggestions!