fetchmail-users — User questions and discussion

Re: [fetchmail-users] Has anyone ever seen "Fetchmail saw more than N timouts while attempting to get mail from ..."

[Michelle K. <lin...@fr...>]

Am 2006-07-15 15:28:46, schrieb Matthias Andree:
> Greetings!

Greetings too

> This message is supposed to be mailed to a user since 4.6.7, but the
> code I've looked at makes it rather unlikely (not to say impossible) to
> ever be mailed on operating systems that I'm used to. Before removing
> the relevant code for the 6.3.5 update, I'd like to know if someone is
> getting these messages.

Hmmm, 4.6.4 was in Debian/Slink for 9 years... and since I use Debian
I have never seen such message, even if my ISP's mailserver was offline
or I had a line drop for some days and fetchmail had tried to poll the
servers severt 1000' times...

Greetings
    Michelle Konzack
    Systemadministrator
    Tamay Dogan Network
    Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
                   50, rue de Soultz         MSM LinuxMichi
0033/6/61925193    67100 Strasbourg/France   IRC #Debian (irc.icq.com)

Re: [fetchmail-users] reasonable poll intervals (was: Re: Rotating the log file)

[Michelle K. <lin...@fr...>]

Am 2006-07-12 08:05:43, schrieb Matthias Andree:

> That's what IMAP's IDLE extension is for, with that, the client will be
> notified of new messages without having to reconnect often.
> Unfortunately, this works only well in 6.3.4 and only if fetchmail is
> polling one account only.

Oops...  A new feature?  This would mean, that I have 180
fetchmails running in the background, one for each user... 

Or do I mis something?

And I have more then 600 Mailboxes to poll...

Oh yes, since my ISP support IMAP (courier) I use expunge 1 to prevent
downloading of messages twice, if I have a line-drop on my 3.5 MBit SDSL.

Greetings
    Michelle Konzack
    Systemadministrator
    Tamay Dogan Network
    Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
                   50, rue de Soultz         MSM LinuxMichi
0033/6/61925193    67100 Strasbourg/France   IRC #Debian (irc.icq.com)

Re: [fetchmail-users] reasonable poll intervals (was: Re: Rotating the log file)

[Michelle K. <lin...@fr...>]

Am 2006-07-12 00:37:51, schrieb Uli Zappe:
> Am 11.07.2006 um 11:37 schrieb Matthias Andree:
> 
> >checking new mail every 3 minutes [is] abusive
> 
> Oooops!?! How so? I use 30 seconds as poll interval. Admittedly, most  
> of the people I know that use fetchmail use something between 60 and  
> 120 seconds, but personally I don't know anyone who would use an  
> interval longer than 120 seconds.

Even if my ISP allow me to do it, <frrenet.de> is hosting arround
5 million mailboxes on around 90 Servers, which mean, 55.000
mailboxes per <mboxXX.freenet.de>.  If all peoples would use
such intervall, no server will handle this load...

Since I have over 600 Mailboxes to poll, located on around 40 mbox-
server I poll it only serial and then only all 10 minutes which is
enough.

Many of those mailboxes must be processed independatly from a MUA,
so changing a MUA to use IMAP over the internet does not work.

(I have my own local Courier running and ALL mails need preprocessing)


Greetings
    Michelle Konzack


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
                   50, rue de Soultz         MSM LinuxMichi
0033/6/61925193    67100 Strasbourg/France   IRC #Debian (irc.icq.com)

Re: [fetchmail-users] Rotating the log file

[Michelle K. <lin...@fr...>]

Am 2006-07-10 20:46:36, schrieb Stephen Allen:
> Rob MacGregor wrote:
> >Have you considered using syslog instead of logfile?
> 
> That would be a good idea if you could control more of what gets logged 
> there.  At the moment, my fetchmail daemon runs every 180 seconds and 
> checks email from half-a-dozen POP3 servers.  Most of it's log is filled 
> with:

Do not run it ad daemont but from your crontab with

   */3 * * * * <user> fetchmail --logfile /path/`date +%Y-%m-%d`.log

which will write dayly named logs

Greetings
    Michelle Konzack


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
                   50, rue de Soultz         MSM LinuxMichi
0033/6/61925193    67100 Strasbourg/France   IRC #Debian (irc.icq.com)

Re: [fetchmail-users] Running fetchmail as root for all users

[Michelle K. <lin...@fr...>]

Am 2006-07-06 08:20:49, schrieb Rob MacGregor:
> On 7/6/06, Stephen Allen <fet...@ro...> wrote:
> >The subject may be a little misleading... in my scenario we have 10 ISP
> >POP3 accounts that map to 8 local users.  The way I set it up a few
> >years ago was fetchmail running as root and collecting mail for all POP3
> >accounts.  I've since discovered that fetchmail is normally run on a
> >per-user basis.
> >
> >Given that the users never log in to a shell, what is the best
> >configuration in my case?  Are there pros/cons of doing it either way?
> 
> There is no need, unless you're passing email directly to a non-SUID
> MDA, to run fetchmail as root.  Indeed, future versions of fetchmail
> will refuse to run as root.  I haven't run fetchmail as root since
> before 6.0 was released and have not had any problems.
> 
> Simply run it as a standard user (say "fetchmail") and have it pass
> email to your MTA.

And if there is no "real" MTA (we use ssmtp) ?  I have tried the setup
as user "fetchmail" and I can not deliver to the other around 180 users.

Sorry for the late question, but I was some month not availlable and
came back from Palestine for 3 weeks (after 8 days prison illegal).

Greetings
    Michelle Konzack
    Systemadministrator
    Tamay Dogan Network
    Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
                   50, rue de Soultz         MSM LinuxMichi
0033/6/61925193    67100 Strasbourg/France   IRC #Debian (irc.icq.com)

[fetchmail-users] fetchmail 6.3.5-beta1 snapshot

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

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

Greetings,

after a few not so easy fixes, I am providing a fetchmail snapshot,
dubbed fetchmail 6.3.5-beta1, for public preview.
Download location: <http://mandree.home.pages.de/fetchmail/>

Changes in fetchmail 6.3.5-beta1 (since 6.3.4 release):

# NEW DEPRECATION WARNINGS:
* The "envelope Received" option may be removed from a future release, because
  the Received header was never meant to be machine-readable, the format varies
  widely, and various other differences in behavior make parsing Received an
  unreliable undertaking. The enveloper option as such will remain though, in
  order to support Delivered-To, X-Envelope-To, X-Original-To and similar.
  See also <http://home.pages.de/~mandree/mail/multidrop>.
* Kerberos IV support may be removed from a future fetchmail release.
* SIGHUP wakeup may be removed from a future fetchmail release and cause it
  to terminate.
* Support for operating systems that are not sufficiently POSIX compliant may be
  removed or operation on such systems may be suboptimal for future releases.

# KNOWN BUGS AND LIMITATIONS:
+* fetchmail expects Received: headers in a particular format when parsing
+  envelopes.

# BUG FIXES:
* For protocols such as IMAP that are not delimited by "." lines, truncate the
  input buffer when the message has been completely read, to avoid taking
  trailing garbage into the message if the terminal CRLF is missing. Fixes
  Debian Bug#312415. (Patch suggested by Mike Jones, Manchester Univ.).
* When using NTLM authentication, use regular IMAP response code handler after
  completing NTLM handshake, for robustness and consistency.
  (Taken from the NetBSD portable packages collection, patch-ac.)
* Support Kerberos installations where krb5.h and perhaps roken.h are in
  .../include/krb5.  Taken from NetBSD portable packages collection patch-ae.
* On NetBSD, link against -lroken -lcom_err if --with-kerberos is enabled.
* Drop #include <com_err.h> from Kerberos 5 header file, fixes compile error on
  SUSE Linux 10.0.
* Fix des_pcbc_encrypt compile warnings in kerberos.c line 246.
* If krb5-config provides gssapi library information, use that rather than
  guessing.
* Improve --with-gssapi auto detection for /usr-based GSSAPI installs.
* Fix --with-gssapi builds for NetBSD 3.0.
* Improve KAME/getnameinfo.c portability to Linux libc5 systems.
  Based on a patch by Dan Fandrich.
* Provide INET6 to KAME/getnameinfo.c (only useful on IPv6-enabled systems that
  lack getnameinfo, and there only visible in some Received: headers).
  Found by Dan Fandrich.
* POP3: some UID flags may not be set properly on UIDL lists. (Sunil Shetye)
* Make IMAP4 IDLE work on servers that do not update RECENT counts.
  Reported by Lars Tewes.
* IMAP4 patch by Sunil Shetye:
  - do not depend on server updating RECENT counts at all
  - also enter IDLE loop when messages are present on the server.
* Fix --flush description in the manual page, fetchmail does not mark messages
  seen unless it has successfully delivered them. Suggested by Frederic Marchal.
* Fetchmail no longer attempts to stat the "-" file in daemon mode -- this is a
  special name to read the RC file from stdin, and cannot always be re-read
  anyways. BerliOS bug #7858.
* When looking up ports for a service, the lookup succeeds and the returned
  address family isn't IPv4 or IPv6, properly free the allocated memory from the
  service lookup. Found by Uli Zappe.
* When looking up ports for a service, only look up TCP ports.
* Avoid compiling empty files, to avoid diagnostics from strict compilers.
* If the lockfile ends before the process ID, treat it as stale and unlink it.
  Reported by Justin Pryzby, Debian Bug #376603.
* SIGHUP wake-up behavior was broken since 5.9.13's Cygwin changes, in that for
  non-root users, SIGHUP would abort the first poll and subsequently interfere
  with new polls, and SIGHUP would be ignored for root users. SIGHUP now matches
  documented behavior. SIGUSR1 has always been a wakeup signal for both root
  (undocumented) and non-root users. See also the deprecation warning above.
* When a connection fails, log not only the IP address, but also host and
  service name and the port number. Log the latter when trying to connect in
  verbose mode, too.
* Keep syslog output at one line per message (this works if no errors occur).
* Track getaddrinfo() results to properly free them after timeouts,
  reported by Uli Zappe.  This MIGHT fix Debian Bug#294547 and Bug#377135.
* Fetchmail in verbose mode now logs if it opportunistically upgrades a POP3
  or IMAP connection to TLS security with STLS/STARTTLS.
* --logfile is now handled more carefully, errors opening the logfile are
  now reported to the TTY where fetchmail was started from.
* fetchmail now complains and aborts when it cannot properly daemonize itself.
* fetchmail now supports fo...@ex...=bar user mappings for multidrop boxes.

# CHANGES:
* Rename all fetchmail-internal lock_* functions to fm_lock_*. Obsoletes
  NetBSD portable packages collection patch-ah, patch-ai and patch-aj.
* Configure prints a warning (but proceeds) if Kerberos IV support is enabled.
* In verbose mode, log every IP fetchmail tries to connect to, to avoid
  misleading the user. Suppress EAFNOSUPPORT errors from socket() call, too.
  Fixes Debian Bug #361825, reported by Daniel Baur.
* In idle mode, fetchmail complains about the fetchall option.

# CONTRIBUTED SCRIPTS:
* PopDel.py was revised by Joshua Crawford to display the From: address and
  list every email, even if it has no Subject: header; and not delete the wrong
  message in the presence of mail without Subject: headers.

Happy fetching,
Matthias Andree
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFE1zgvvmGDOQUufZURAkhgAJ4zllZl0gWjJ9kD6Um9I6uWXAoO2ACfS9I2
NZYdxTe1Gd5yZN0xpKn31mc=
=9bIu
-----END PGP SIGNATURE-----

Re: [fetchmail-users] Multi-drop problems

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

Matthias Andree <mat...@gm...> writes:

> Well, fetchmail doesn't support full addresses in user mappings yet,
> thus you'll need to rewrite your configuration a bit, hoping that
> (mypartner) is different from (username) and that
> (mypartner) is also different from (myname).

I have just implemented full-address mappings (as Andrew Longland-Meech
tried in his original configuration), to appear in the upcoming
fetchmail 6.3.5 version.

These full-address mappings will apply after qvirtual stripping and have
highest precedence, i. e. they are valid even if no localdomains, aka,
via or DNS alias matches are found.

-- 
Matthias Andree

Re: [fetchmail-users] Error 550 fetchmail-postfix-cyrus

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

Kwadwo Owusu schrieb am 2006-08-03:

>                        The Postfix program
> 
> <ro...@ox...> (expanded from
>    <pos...@lo...>): host
>    /var/lib/imap/socket/lmtp[/var/lib/imap/socket/lmtp] said: 550-Mailbox
>    unknown.  Either there is no mailbox associated with this 550-name or you
>    do not have authorization to see it. 550 5.1.1 User unknown (in reply to
>    RCPT TO command)

It's hard to tell what exactly went wrong. Generally, you have two
options (I'm not sure if webmin supports one, the other, or both - in
doubt, check with SUSE - you've got their commercial product after all).

- map the postmaster to an existing user at your site with Postfix aliases,
  check the Postfix configuration and manual

- configure fetchmail to send root messages to the right user:
  set postmaster "us...@do..." (put this before the first "poll"
  stanza)

HTH,

-- 
Matthias Andree

[fetchmail-users] Error 550 fetchmail-postfix-cyrus

[Kwadwo O. <kwa...@gm...>]

I have installed Open-xchange on SLES9 for a client. We have a DSL
connection to the Internet. Unfortunately the provider will not give
us a static public IP. We have a POP3 account with a mail hosting
provider that up till now the client has been using a web interface to
access mail for one user. The account has now been turned into a
catchall for the domain (Multidrop)

I have configured fetchmail (using webmin) to pull all mails destined
for the clients domain to the mail server running postfix and cyrus.
This works, but I get the error message 550 from postfix (actual
domain name changed to anydomain.com):

This is the Postfix program at host ox.anydomain.com.

I'm sorry to have to inform you that your message could not be
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to <postmaster>

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                       The Postfix program

<ro...@ox...> (expanded from
   <pos...@lo...>): host
   /var/lib/imap/socket/lmtp[/var/lib/imap/socket/lmtp] said: 550-Mailbox
   unknown.  Either there is no mailbox associated with this 550-name or you
   do not have authorization to see it. 550 5.1.1 User unknown (in reply to
   RCPT TO command)


Final-Recipient: rfc822; ro...@ox...
Original-Recipient: rfc822; pos...@lo...
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Postfix; host
   /var/lib/imap/socket/lmtp[/var/lib/imap/socket/lmtp] said: 550-Mailbox
   unknown.  Either there is no mailbox associated with this 550-name or you
   do not have authorization to see it. 550 5.1.1 User unknown (in reply to
   RCPT TO command)

Using open-xchange i created the accounts with simple first names for
the staff for example  paul, angela, etc.  and the email addresses as
fir...@do.... Only one person, the md, has his account as
p.mueller and his email address as p.m...@do...

The server's host and domain name was configured in ldap during the
sles9 installation.

In fetchmail I run a single fetchmailrc for all users, using the (*)
as a catchall for all local users.

Any help to rectify this problem would be much appreciated.


Kwadwo Owusu

Re: [fetchmail-users] Multidrop fetchmail bouncing non-existing local addresses

[Andy H. <adh...@gm...>]

Hi,

On 7/31/06, Matthias Andree <mat...@gm...> wrote:
> I'll take a look as my time permits.
>
> 8-)

That's all I can ask for :)

Andy

Re: [fetchmail-users] Multidrop fetchmail bouncing non-existing local addresses

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

"Andy Hawkins" <adh...@gm...> writes:

> Hi,
>
> On 7/28/06, Rob MacGregor <rob...@gm...> wrote:
>> You've probably missed the fact that these days Matthias pretty much
>> is the entire fetchmail development team (or at least all of it you'll
>> see on the lists, I think some of the others are still around, if not
>> terribly active).  This means that there isn't a lot of developer time
>> available, hence why you rarely see him on the lists.
>
> Not so much 'missed' as 'didn't know'.
>
> My 'hurry up' e-mail was in no way intended to show dissatisfaction in
> the responses I was receiving, more a reminder to people that I was
> still interested in an answer.
>
> A simple 'I'll take a look at it when I have time' was all I was looking for.

I'll take a look as my time permits.

8-)

-- 
Matthias Andree

Re: [fetchmail-users] Multidrop fetchmail bouncing non-existing local addresses

[Andy H. <adh...@gm...>]

Hi,

On 7/28/06, Rob MacGregor <rob...@gm...> wrote:
> You've probably missed the fact that these days Matthias pretty much
> is the entire fetchmail development team (or at least all of it you'll
> see on the lists, I think some of the others are still around, if not
> terribly active).  This means that there isn't a lot of developer time
> available, hence why you rarely see him on the lists.

Not so much 'missed' as 'didn't know'.

My 'hurry up' e-mail was in no way intended to show dissatisfaction in
the responses I was receiving, more a reminder to people that I was
still interested in an answer.

A simple 'I'll take a look at it when I have time' was all I was looking for.

Cheers

Andy

Re: [fetchmail-users] Simple fetch and forward

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

"John" <fet...@je...> writes:

> X-Original-To isn't always there. If I get a mail directed at a mailing list
> or sent as a bcc then it isn't always obvious what the sender was.

So it's not your upstream writing that header?

> When the message hits procmail, I run a little script and this
> extracts a likely original destination address, irrespective if it was
> sent Bcc or via a list,

This works in good weather, and fails in bad unfortunately.

> I was originally trying to use Fetchmail's multidrop mode to do what I
> wanted but I didn't fully understand the anatomy of an email so I read
> the RFC and re-thought what I was doing. I don't know if I am doing
> this the best way, but what I've got works for me - it's just a
> prototype but it seems to be ok.

The best is if your POP3 or IMAP service provider adds some reliable
header, be it Delivered-To:, X-Original-To:, X-Envelope-To: or
similar. If they don't, ask them if they can do that.

<http://home.pages.de/~mandree/mail/multidrop> sums up requirements for
multidrop in a way that is a tad less technical than a RFC.

-- 
Matthias Andree

Re: [fetchmail-users] Simple fetch and forward

[John <fet...@je...>]

>If your inbound server writes X-Original-To: headers, why is a script
needed?

>--
>Matthias Andree

Hi Matthias,

X-Original-To isn't always there. If I get a mail directed at a mailing list
or sent as a bcc then it isn't always obvious what the sender was.

I'm using fetchmail to receive the mail and drop it to a user on my server.
When
my Postfix gets that mail it can add an X-Original-To but this will be the
name of
the account specified in the "here" clause in fetchmail conf. This is not of
much
use so I don't do that. I did do this originally but soon realised there was
little point.

When the message hits procmail, I run a little script and this extracts a
likely
original destination address, irrespective if it was sent Bcc or via a list,
by
extracting the "Received:" header containing a "for" nearest the mail's
origin.
Procmail then delivers the mail into a user folder based on the address that
was
extracted: if the mail was destined for "ad...@do..." it hits a
folder called
domain.com/address. This is great as it sorts all my incoming mail from
various
services I subscribe to (I subscribe with a unique address to each one so I
can
track where my address is leaked from as I get spam).

I was originally trying to use Fetchmail's multidrop mode to do what I
wanted but
I didn't fully understand the anatomy of an email so I read the RFC and
re-thought
what I was doing. I don't know if I am doing this the best way, but what
I've got
works for me - it's just a prototype but it seems to be ok.

Thanks for your interest,
John

Re: [fetchmail-users] Multidrop fetchmail bouncing non-existing local addresses

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

On 7/28/06, Andy Hawkins <adh...@gm...> wrote:
>
> And in fairness, I did leave over a week between my original request
> and the reminder...

You've probably missed the fact that these days Matthias pretty much
is the entire fetchmail development team (or at least all of it you'll
see on the lists, I think some of the others are still around, if not
terribly active).  This means that there isn't a lot of developer time
available, hence why you rarely see him on the lists.

You're welcome to try the original maintainer, ESR, but some of us
have been trying to get a response from him for literally years now :)

-- 
                 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] Simple fetch and forward

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

"John" <fet...@je...> writes:

> I now let a user's mail hit Postfix as that user and I have written a small
> script that scans the mail and makes a "best guess" at the intended
> recipient by parsing the "Received", "Envelope-to" and "X-Original-To"
> fields.

If your inbound server writes X-Original-To: headers, why is a script needed?

-- 
Matthias Andree

Re: [fetchmail-users] Multidrop fetchmail bouncing non-existing local addresses

[Andy H. <adh...@gm...>]

Hi,

On 7/27/06, Matthias Andree <mat...@gm...> wrote:
> Hang on, you haven't paid 24x7 2-hour response support level.
> I've seen your questions, but not yet found the necessary time for research.

Apologies, I just wanted to make sure someone else had seen it. I
realise that support here is worth every penny I pay for it :)

And in fairness, I did leave over a week between my original request
and the reminder...

> you'll *have* to wait until it's your turn.

Understood.

Andy

Re: [fetchmail-users] Simple fetch and forward

[John <fet...@je...>]

Rob thanks for your suggestions.

I decided to step back from the problem. I've taken a day or so to read the
RFC material describing message formats and I have studied several incoming
messages. I now realise I can not expect the header information to contain
what I thought and have approached the problem from another angle.

I now let a user's mail hit Postfix as that user and I have written a small
script that scans the mail and makes a "best guess" at the intended
recipient by parsing the "Received", "Envelope-to" and "X-Original-To"
fields. I then deliver mail into a user folder from within Procmail by
altering the argumets to the deliver script, delivering into Cyrus imap.

Thanks for taking the time to respond to my query.

-----Original Message-----
From: fet...@li...
[mailto:fet...@li...]On Behalf Of Rob
MacGregor
Sent: 24 July 2006 21:21
To: fet...@li...
Subject: Re: [fetchmail-users] Simple fetch and forward

Re: [fetchmail-users] Multidrop fetchmail bouncing non-existing local addresses

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

"Andy Hawkins" <adh...@gm...> writes:

>> Ok. I've found a workaround by changing the postmaster setting to an
>> empty string. However, I suspect that's not a particularly good
>> idea...
>
> Anyone? ???

Hang on, you haven't paid 24x7 2-hour response support level.
I've seen your questions, but not yet found the necessary time for research.

Send 30 Euro via PayPal and I'll look at your issue ASAP as long
as it doesn't take longer than 20 minutes (and send what I figured in
that period), else you'll *have* to wait until it's your turn.

-- 
Matthias Andree

Re: [fetchmail-users] [fetchmail]Multidrop fetchmail bouncing non-existing local addresses

[Andy H. <adh...@gm...>]

Hi,

On 7/19/06, Andy Hawkins <adh...@gm...> wrote:
> Hi,
>
> On 7/18/06, Rob MacGregor <rob...@gm...> wrote:
> > Give it another couple of days.  I'm reasonably sure somebody with
> > knowledge of the source will be by before the weekend.  The
> > development team is pretty small (not sure of the exact number, but I
> > suspect only 2 or 3).
>
> Ok. I've found a workaround by changing the postmaster setting to an
> empty string. However, I suspect that's not a particularly good
> idea...

Anyone? ???

Andy

Re: [fetchmail-users] Server CommonName mismatch

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

On 7/25/06, N.J. Mann <nj...@nj...> wrote:
> Hi,
>
> I have been using fetchmail for about three weeks now and I am very
> happy with it.  But... (You knew a "but" was going to be next. ;-) )
>
> Every time I poll my ISP I get the following errors:
>
> fetchmail: Server CommonName mismatch: localhost.localdomain != inmail.njm.f2s.com
> fetchmail: Server certificate verification error: self signed certificate

There was a recent thread on this.  The summary (assuming you don't
want to read the thread) was to either use an ISP with a clue, or do
what Volker advised and use the fingerprints.

-- 
                 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] Server CommonName mismatch

[Volker K. <hi...@pa...>]

> fetchmail: Server CommonName mismatch: localhost.localdomain != inmail.njm.f2s.com
> fetchmail: Server certificate verification error: self signed certificate

> So it looks like fetchmail is complaining about my ISPs setup.  Is that
> right?

Yes. Your ISP is using a self-baked certificate; it's cheap (i.e. free).
On the negative, your fetchmail (and browser, etc) have no idea whether
your ISP is trustworthy, or is in fact the person/entity it claims to
be. To teach fetchmail about both, you need to load your ISP's CA
(certificate authority) into your openssh setup. By doing so, you
personally assume liability for aforementioned claims to be true.

The use of certificates here is to increase security. Security here
means:

1) Each time you run fetchmail, the connection which is opened is
guaranteed to be to <someone> at the other end. You expect that someone
to be your ISP.

2) The connection is encrypted, and protected from eavesdropping by
anyone other than a) yourself, b) that "someone".

The trick is to make sure that the "someone" is in fact your ISP. With
self-signed certificates, the only guaranteed way to do so is to jump
into your car and to pick up the CA from your ISP in person.

The shortcut is to read out your ISP's certificate fingerprint, and to
load this into fetchmail 6.3.4 or above. This solves your problem, but
you then have two possibilities when you've loaded the fingerprint:

1) You loaded the fingerprint of your ISP's CA into fetchmail. You have
security as good as it'll possibly get. Self-signed cert or otherwise.

2) You loaded the fingerprint of an imposter, assuming the imposter to
be your ISP. Both you and the imposter will read your email.

Your alternative is quite likely using plain text passwords. Even
possibility 2) is an improvement to that, because reading your email is
restricted from everyone, to you and the imposter.

Volker

-- 
Volker Kuhlmann			is list0570 with the domain in header
http://volker.dnsalias.net/	Please do not CC list postings to me.

[fetchmail-users] Server CommonName mismatch

[N.J. M. <nj...@nj...>]

Hi,

I have been using fetchmail for about three weeks now and I am very
happy with it.  But... (You knew a "but" was going to be next. ;-) )

Every time I poll my ISP I get the following errors:

fetchmail: Server CommonName mismatch: localhost.localdomain != inmail.njm.f2s.com
fetchmail: Server certificate verification error: self signed certificate

At first I throught the first one was due to something I was doing
wrong, but I now suspect it is nothing to do with me.  Can someone
confirm that please?  My change of mind stems from running
fetchmail -v -v -v and redirecting the output to a log file.  (The idea
for that came from a message I read earlier today on this list, so
lurking here for a while does pay. :-) )

In the log I get:

fetchmail: Old UID list from inmail.njm.f2s.com: <empty>
fetchmail: Scratch list of UIDs: <empty>
fetchmail: 6.3.4 querying inmail.njm.f2s.com (protocol POP3) at Tue Jul 25 10:43:33 2006: poll started
fetchmail: POP3< +OK imap3.freedom2surf.net Cyrus POP3 v2.2.12-Invoca-RPM-2.2.12-7 server ready <122...@im...>
fetchmail: POP3> CAPA
fetchmail: POP3< +OK List of capabilities follows
fetchmail: POP3< SASL DIGEST-MD5 CRAM-MD5
fetchmail: POP3< STLS
fetchmail: POP3< EXPIRE NEVER
fetchmail: POP3< LOGIN-DELAY 0
fetchmail: POP3< TOP
fetchmail: POP3< UIDL
fetchmail: POP3< PIPELINING
fetchmail: POP3< RESP-CODES
fetchmail: POP3< AUTH-RESP-CODE
fetchmail: POP3< USER
fetchmail: POP3< IMPLEMENTATION Cyrus POP3 server v2.2.12-Invoca-RPM-2.2.12-7
fetchmail: POP3< .
fetchmail: POP3> STLS
fetchmail: POP3< +OK Begin TLS negotiation now
fetchmail: Issuer Organization: SomeOrganization
fetchmail: Issuer CommonName: localhost.localdomain
fetchmail: Server CommonName: localhost.localdomain
fetchmail: inmail.njm.f2s.com key fingerprint: E1:A1:1A:47:61:46:97:6D:F3:9D:BF:13:59:40:EA:E3
fetchmail: POP3> CAPA

(I hope my MUA hasn't mangled that too much.)

So it looks like fetchmail is complaining about my ISPs setup.  Is that
right?

For reference, I am running fetchmail 6.3.4 on FreeBSD v6.1 (STABLE).

Thanks in advance.

Cheers,
Nick.
-- 
"We're predicting third stage shutdown at 11 minutes 42 seconds."

Re: [fetchmail-users] Simple fetch and forward

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

On 7/24/06, John <fet...@je...> wrote:
> Fetchmail 6.3.4

That avoids the usual "upgrade to the latest version" chant :-)

> >2) Contents of .fetchmailrc
<---SNIP--->
> I was previously trying:
>
> poll mail.ispmailserver.net protocol pop3
>     aka forwarder1.com
>     envelope Received

(This is almost certainly your problem)

>     localdomains domain1.com domain2.com domain3.com
>     user my-username there pass my-password to * here

That's pretty close to what I've got, and it works for me.

I suspect the problem relates to the overloading of the Received
header.  Does your ISP use a Delivered-to or Envelope-to header?

> fetchmail: line rejected, four.mx.forwarder1.com is not an alias of the
> mailserver

Try the options below and, if it still fails, provide the output of
"fetchmail -v -v -v" for a BCC email.  That email's headers would help
too.

> Fetchmail seems to want to change headers and this is confusing things. If I
> can just get it to pass stuff through verbatim then I think it'll be ok.

You probably want to add the options to "set invisible" and "no rewrite".

-- 
                 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] Simple fetch and forward

[John <fet...@je...>]

>You can (that's what I'm doing).  What you're missing is providing us
>with any information to help you.

>So,

>1) Fetchmail version
Fetchmail 6.3.4

>2) Contents of .fetchmailrc

I've tried so many variants of the fetchmailrc file I don't really have
"one" to send. Here is what I have at the moment:

set logfile /var/log/fetchmail.log
set no bouncemail
set postmaster root
set daemon 1500

poll mail.ispmailserver.net protocol pop3
    user my-username pass my-password

I was previously trying:

poll mail.ispmailserver.net protocol pop3
    aka forwarder1.com
    envelope Received
    localdomains domain1.com domain2.com domain3.com
    user my-username there pass my-password to * here

I had to put in aka to get mail that had been forwarded by my domain's DNS
to be recognised when the Received lines were parsed. Without this I got the
below error on a Bcc:

fetchmail: line rejected, four.mx.forwarder1.com is not an alias of the
mailserver

The localdomains are my domains. This latter configuration is probably
nonsense but it got me close (but not exactly) to what I am trying to do. It
works for a specific case but is not really a solution.

Fetchmail seems to want to change headers and this is confusing things. If I
can just get it to pass stuff through verbatim then I think it'll be ok.

All help is much appreciated.