fetchmail-users — User questions and discussion

[fetchmail-users] fetchmail 6.3.4 now also available from ibiblio.org

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

Greetings,

I just received notice that fetchmail 6.3.4 is also available from
ibiblio.org, and their mirrors as they resynch.

The ibiblio path is system/mail/pop/fetchmail/.

In order to download fetchmail from ibiblio.org mirrors:

1. look up a mirror close to you from
<http://www.ibiblio.org/pub/linux/MIRRORS.html>

2. add system/mail/pop/fetchmail/!INDEX.html to the URL you just looked up

3. download fetchmail-6.3.4.tar.bz2

Kind regards
Matthias Andree

Re: [fetchmail-users] Exchange server and attachment

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

On 5/2/06, Andres Baravalle <an...@ba...> wrote:
> no output again...

Right, you'll need to disable daemon mode too:

fetchmail --nosyslog -d0 -v -v

> Connecting to my work server works with thunderbird, both on windows and
> on Linux.

Thanks, that at least suggests a problem with the interaction of
fetchmail and exchange.  Hopefully once you manage to get the output
requested, showing a corrupt attachment download, we'll be able to
narrow down the problem.

--
                 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] Exchange server and attachment

[Andres B. <an...@ba...>]

Rob MacGregor wrote:
> On 4/28/06, Andres Baravalle <an...@ba...> wrote:
>> could you explain a bit more what you mean? If I run the command I do
>> not see any output, nor there is any tput in /var/log/messages.
> 
> Please post your .fetchmailrc.

Hi,
here is my configuration file:

set postmaster "an...@ba..."
set bouncemail
set daemon 60
set syslog

poll *******
     protocol imap
     port 993
     user '****'
     pass '****'
     is and...@ba...
     ssl
     keep

> For the first, try "fetchmail --nosyslog -v -v".  It's likely you're
> logging to syslog if there is not output on stdout.

no output again...

>> Yes, I can confirm you that I can read the email from Thunderbird.
> 
> On the host you're running fetchmail on?

I have limits in the amount of space I can use in my work address. So I
run fetchmail to get my mail from my work address to my personal server.
And then I connect from other hosts to read the email.

Connecting to my work server works with thunderbird, both on windows and
on Linux.

Hope

Re: [fetchmail-users] Hello i have problem :(

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

On 4/29/06, Ozgur YILMAZ <mr...@gm...> wrote:
>
> i want to local spam scanner for office
> i setup fetchmail + qmail + vpopmail + qmailscanner + SA
>
> i fetch mail by fetchmail and i recived qmail pop3
> and SA works test command but my fetch mail is not scanned by SA

Why not tie SA into qmail and avoid the mda command you're using?

If that's not possible you'll need to show log entries showing your problem.

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

[fetchmail-users] Hello i have problem :(

[Ozgur Y. <mr...@gm...>]

i want to local spam scanner for office
i setup fetchmail + qmail + vpopmail + qmailscanner + SA

i fetch mail by fetchmail and i recived qmail pop3
and SA works test command but my fetch mail is not scanned by SA

here my .fetchmailrc

poll my.externalserver.com protocol pop3
user 'oz...@ne...' there with password 'mypass' is
'de...@co...' here
mda "/usr/bin/spamc -e | /var/spool/qmailscan/qmail-queue" ( i have problem
this line i do not write )

please help me :(

özgür

Re: [fetchmail-users] Exchange server and attachment

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

On 4/28/06, Andres Baravalle <an...@ba...> wrote:
> could you explain a bit more what you mean? If I run the command I do
> not see any output, nor there is any tput in /var/log/messages.

Please post your .fetchmailrc.

For the first, try "fetchmail --nosyslog -v -v".  It's likely you're
logging to syslog if there is not output on stdout.

> Yes, I can confirm you that I can read the email from Thunderbird.

On the host you're running fetchmail on?

--
                 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] Exchange server and attachment

[Andres B. <an...@ba...>]

Rob MacGregor wrote:
> On 4/28/06, Andres Baravalle <an...@ba...> wrote:
> It would help to see the .fetchmailrc and the output of "fetchmail -v
> -v" showing a pull of a "corrupt" attachment.

Hi,
could you explain a bit more what you mean? If I run the command I do
not see any output, nor there is any tput in /var/log/messages.

> Confirmation that a normal client (such as Thunderbird) can download a
> mail without corruption of attachments would be useful (using the same
> host as you're running fetchmail on, using the same config).

Yes, I can confirm you that I can read the email from Thunderbird.

Thanks in advance for your help,
	Andres

Re: [fetchmail-users] Exchange server and attachment

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

On 4/28/06, Andres Baravalle <an...@ba...> wrote:
> Dear all,
> I'm fetching my email from an exchange server and I have regular
> problems with the attachments. Attachments are often corrupted.
>
> I have read the FAQs and apparently there are some known problems, and
> the suggested solution is to change email server. Which of course I
> can't because is not in my control.
>
> I was wondering:
> -if the FAQ entry is updated, and if there are still known problems
> -if it might be a configuration problem on my side.

It would help to see the .fetchmailrc and the output of "fetchmail -v
-v" showing a pull of a "corrupt" attachment.

Confirmation that a normal client (such as Thunderbird) can download a
mail without corruption of attachments would be useful (using the same
host as you're running fetchmail on, using the same config).

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

[fetchmail-users] Exchange server and attachment

[Andres B. <an...@ba...>]

Dear all,
I'm fetching my email from an exchange server and I have regular
problems with the attachments. Attachments are often corrupted.

I have read the FAQs and apparently there are some known problems, and
the suggested solution is to change email server. Which of course I
can't because is not in my control.

I was wondering:
-if the FAQ entry is updated, and if there are still known problems
-if it might be a configuration problem on my side.

This is the output of fetchmail -V

This is fetchmail release 6.3.4+SSL+NLS.

Fallback MDA: (none)
Linux server.com 2.4.21-37.ELsmp #1 SMP Wed Sep 28 14:05:46 EDT 2005
i686 i686 i386 GNU/Linux
Taking options from command line and /user/.fetchmailrc
Poll interval is 60 seconds
Idfile is /user/.fetchids
Progress messages will be logged via syslog
Fetchmail will forward misaddressed multidrop messages to
an...@ba....
Options for retrieving from ab...@ou...:
  True name of server is server.ac.uk.
  Protocol is IMAP (using service 993).
  All available authentication methods will be tried.
  SSL encrypted sessions enabled.
  Server nonresponse timeout is 300 seconds (default).
  Default mailbox selected.
  Only new messages will be retrieved (--all off).
  Fetched messages will be kept on the server (--keep on).
  Old messages will not be flushed before message retrieval (--flush off).
  Oversized messages will not be flushed before message retrieval
(--limitflush off).
  Rewrite of server-local addresses is enabled (--norewrite off).
  Carriage-return stripping is disabled (stripcr off).
  Carriage-return forcing is disabled (forcecr off).
  Interpretation of Content-Transfer-Encoding is enabled (pass8bits off).
  MIME decoding is disabled (mimedecode off).
  Idle after poll is disabled (idle off).
  Nonempty Status lines will be kept (dropstatus off)
  Delivered-To lines will be kept (dropdelivered off)
  Fetch message size limit is 100 (--fetchsizelimit 100).
  Do binary search of UIDs during 3 out of 4 polls (--fastuidl 4).
  Messages will be SMTP-forwarded to: localhost (default)
  Single-drop mode: 1 local name recognized.
  No UIDs saved from this host.

Thanks in advance,
	Andres

____________

Andres Baravalle
http://www.baravalle.it

____________

Gli uomini d'azione sono poco pratici.
La stessa azione li allontana dalla loro meta.
         Paco Ignacio Taibo I

Re: [fetchmail-users] Re: "Seen" status disappears everytime

[Rob F. <rf...@fu...>]

Ratan Nalumasu wrote:
> Matthias:
>
> I think I understand the confusion on "read" vs. "unread"
> status.
> What I want is the mail on server to disappear and the mail on
> laptop to have "read" or "unread" according to what was on the
> server before the fetch started. What is happening is that the
> mail on the server is disappearing (as I want), but all mail on
> the laptop is unread (disconcerting).

OK, so you're starting with a message in your mailbox with a header of 
"Status: RO".  Programs on the server sees it as old and read.  fetchmail 
downloads with IMAP, and you no longer have that Status header telling 
your local elm that it's old and read.

I think the pop/imap server is the one removing the Status header, since 
that's just a feature of the mbox format that tells the mailreader (e.g. 
elm or the imap server) whether the mail is read.  It isn't intended to 
be preserved outside the mbox.

By the time fetchmail gets the message, that Status header is already 
gone; it has been translated into IMAP flags, which you're basically 
ignoring when you tell fetchmail to fetchall.

If I'm correct, what you're asking for is basically for fetchmail to look 
at those IMAP flags and translate them back into a Status header to be 
added to the mail.  I'm not sure that's a feature very likely to make it 
into fetchmail.

-- 
==============================|   "A microscope locked in on one point
 Rob Funk <rf...@fu...> |Never sees what kind of room that it's in"
 http://www.funknet.net/rfunk |    -- Chris Mars, "Stuck in Rewind"

Re: [fetchmail-users] Re: "Seen" status disappears everytime

[Ratan N. <nal...@ya...>]

Matthias:

I think I understand the confusion on "read" vs. "unread"
status.
What I want is the mail on server to disappear and the mail on
laptop to have "read" or "unread" according to what was on the
server before the fetch started. What is happening is that the
mail on the server is disappearing (as I want), but all mail on
the laptop is unread (disconcerting).

--- Matthias Andree <mat...@gm...> wrote:

> Ratan Nalumasu <nal...@ya...> writes:
[...]
> > - The mailserver currently has IMAP and POP3 ports open,
> >   though POP3 may be closed in the future. There is no
> server
> >   on the POP3S port as we speak though.
> 
> Does the POP3 port offer STLS? If it does, no need for POP3S.

Yes, it does. Ok, at least one less thing to worry about.

[...]

> > - I sometimes read the mail directly on the mail server
> >   using squirrelmail and elm.
> 
> That will only work until fetchmail has downloaded the
> messages. After
> that, your requirement "empty mailbox after fetch" prevents
> that.

That is a good thing for me. I login to the mail sever or use
squirrelmail infrequently (e.g., when I am on the road and don't
have access to laptop). Once I am back in the office, I want to
fetch all the mails along with their status.

> > In these cases, the messages are being marked as Read on the
> server
> > ("Status: RO").  However, when I get them using fetchmail on
> IMAP
> > protocol, the Status line disappears in the fetched e-mail.
> 
> This looks a bit like a server issue. Fetchmail would mark
> downloaded
> messages read (rather than marking read messages unread), but
> as per
> your description the effect is quite the opposite.

I think here, you are stating that fetchmail would mark the
messages on the server as read, right? That is true. After this
step, as you find below, the fetchmail does mark it as deleted
and expunge it--that is good too. My trouble with the mail on
the laptop.

> What I find most peculiar though is that (judging from the -v
> -v log)
> fetchmail marks the messages as seen and deleted, sends an
> EXPUNGE
> command that logs the two messages as expunged, and apparently
> the
> messages are still there (else you wouldn't have messages
> marked unread,
> but the messages should be gone). Any idea?
> 
> > - When I fetch the same mail using fetchmail on POP3
> protocol,
> >   the "Status" fields are retained but it leads to a
> different
> >   problem: insufficient integration with ssh/ssh-agent.
> 
> Yes, that requires some experimenting on how exactly to start
> the
> server, and not all support it, since it's not standardized.
> 
[...]

Thanks much for the help
Ratan

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [fetchmail-users] Re: "Seen" status disappears everytime

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

Ratan Nalumasu <nal...@ya...> writes:

> Hi all:
>
> I am still struggling a bit with the configuration. As
> suggested, I am going to describe what I am trying to achieve
> and then explain what I have done so far.
>
> - I want to download mail from the mailserver to my laptop,
>   leaving an empty mailbox on the server.

That alone is easy. Don't use --keep and perhaps use --fetchall.

> - The mailserver currently has IMAP and POP3 ports open,
>   though POP3 may be closed in the future. There is no server
>   on the POP3S port as we speak though.

Does the POP3 port offer STLS? If it does, no need for POP3S.

> - Ideally, I don't want to enter the password to fetchmail,
>   but have it use my ssh-agent if available and fail if not.

Your configuration does that.

> - I sometimes read the mail directly on the mail server
>   using squirrelmail and elm.

That will only work until fetchmail has downloaded the messages. After
that, your requirement "empty mailbox after fetch" prevents that.

> In these cases, the messages are being marked as Read on the server
> ("Status: RO").  However, when I get them using fetchmail on IMAP
> protocol, the Status line disappears in the fetched e-mail.

This looks a bit like a server issue. Fetchmail would mark downloaded
messages read (rather than marking read messages unread), but as per
your description the effect is quite the opposite.

What I find most peculiar though is that (judging from the -v -v log)
fetchmail marks the messages as seen and deleted, sends an EXPUNGE
command that logs the two messages as expunged, and apparently the
messages are still there (else you wouldn't have messages marked unread,
but the messages should be gone). Any idea?

> - When I fetch the same mail using fetchmail on POP3 protocol,
>   the "Status" fields are retained but it leads to a different
>   problem: insufficient integration with ssh/ssh-agent.

Yes, that requires some experimenting on how exactly to start the
server, and not all support it, since it's not standardized.

> After some research, I tried the following to force it to use
> ssh; but the results were still not good: this configuration
> still asks for password; if I enter a bad password, the
> authentication fails: i.e., apparently, unlike imap server, the
> pop3 server has no preauthorized state.

Well, it's possible to trick some servers into a similar state, but
sometimes this requires wrapper scripts to get synchronization (who
talks first) right.

> ==== pop3, attempt#2 ===
> poll bitter with pop3 via localhost port 8005
>    uidl
>    preconnect "ssh -n -2 -a -C -f ratan@bitter -L
> 8005:bitter:110 sleep 5"
>
> ======
>
> Any suggestions on how I can get the mail while retaining the
> "Seen" flags exclusively using the ssh-agent for connection
> would be great.
>
> BTW, I tried fetchmail version 6.3.4 and 6.2.5.2 both with the
> same results.

The basic code and how it works is mostly unchanged, but 6.3.4 has a
slew of bugs less than 6.2.5.X, so you might want to stick with 6.3.4
nonetheless.

-- 
Matthias Andree

[fetchmail-users] Re: "Seen" status disappears everytime

[Ratan N. <nal...@ya...>]

Hi all:

I am still struggling a bit with the configuration. As
suggested, I am going to describe what I am trying to achieve
and then explain what I have done so far.

- I want to download mail from the mailserver to my laptop,
  leaving an empty mailbox on the server.

- The mailserver currently has IMAP and POP3 ports open,
  though POP3 may be closed in the future. There is no server
  on the POP3S port as we speak though.

- Ideally, I don't want to enter the password to fetchmail,
  but have it use my ssh-agent if available and fail if not.

- I sometimes read the mail directly on the mail server
  using squirrelmail and elm. In these cases, the messages
  are being marked as Read on the server ("Status: RO").
However,
  when I get them using fetchmail on IMAP protocol, the Status
  line disappears in the fetched e-mail.

- When I fetch the same mail using fetchmail on POP3 protocol,
  the "Status" fields are retained but it leads to a different
  problem: insufficient integration with ssh/ssh-agent.

I tried the following configuration with IMAP protocol with the
result that all fetched mails were appearing as brand new:


=== IMAP config ===
set postmaster "ratan"
set bouncemail
set no spambounce
set properties ""
defaults mda "/usr/bin/procmail -d %T"

poll bitter
    plugin "env -u DISPLAY /home/ratan/bin/%h exec
/usr/local/bin/imapd" auth ssh;
    user 'ratan' there is 'ratan' here
    expunge 10
    options fetchall
    mda "cat >> /home/ratan/TEST"

=================

I tried the following configuration with POP3 at the suggestion
of Matthias. This almost worked except that it is not using SSH.

=== pop3, attempt#1 ===
poll bitter with pop3
   uidl
   options fetchall

=========

After some research, I tried the following to force it to use
ssh; but the results were still not good: this configuration
still asks for password; if I enter a bad password, the
authentication fails: i.e., apparently, unlike imap server, the
pop3 server has no preauthorized state.

==== pop3, attempt#2 ===
poll bitter with pop3 via localhost port 8005
   uidl
   preconnect "ssh -n -2 -a -C -f ratan@bitter -L
8005:bitter:110 sleep 5"

======

Any suggestions on how I can get the mail while retaining the
"Seen" flags exclusively using the ssh-agent for connection
would be great.

BTW, I tried fetchmail version 6.3.4 and 6.2.5.2 both with the
same results.

Thanks!
Ratan

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [fetchmail-users] "Seen" status disappears everytime [Resending]

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

Ratan Nalumasu <nal...@ya...> writes:

> I read the FAQ, man pages and tried several settings to solve a 
> simple problem "how to retain Seen flag when fetching mail with
> fetchmail" and met with complete failure.
>
> The problem is that when I read the mail on the server using
> elm, mailx, or squrrelmail, they all agree on what message is
> previously read and what is not. However, when I fetch the mail
> using fetchmail, those status bits are disappearing. I am
> attaching my .fetchmailrc, the contents of the mailbox before
> the fetchmail, output of "fetchmail -v -v", and the mailbox
> after the mail is fetched. Any help is welcome.

I see you're using IMAP, and unfortunately, fetchmail relies on the
\Seen flags stored on the server to determine which messages to download
with IMAP -- in your situation for instance, it will not download
messages that you've read with squirrelmail or elm at all.

There aren't many options out of this situation. You could theoretically
use "--fetchall --nokeep", but then squirrelmail could no longer be
used. If the server offers POP3 access, you can try POP3 with --uidl (or
the uidl option), fetchmail will use "TOP" to retrieve messages, which
works on most servers without setting seen flags. Some servers (such as
Dovecot) also don't set seen flags in IMAP when the message has been
retrieved with POP3.

A future fetchmail version (6.4.0 or something) will be able to track
the UID to see which messages are read or unread with IMAP as well (and
not just POP3), but that code has yet to be written.

Finally, fetchmail 6.2.5.* isn't officially supported any more (though
it may still be covered by vendor support), and 6.2.5.2 needs additional
patches (errata or something) to fix security bugs CVE-2005-3088 and
CVE-2005-4348. While they aren't major issues (one affects fetchmailconf
and the other multidrop), your vendor should have fixed them. Details at
http://www.fetchmail.info/

Anyways, I hope my answer helped you find a way around your problem. If
not, try describing what you're trying to achieve, perhaps somebody
knows a solution.

-- 
Matthias Andree

Re: [fetchmail-users] "Seen" status disappears everytime [Resending]

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

On 4/21/06, Ratan Nalumasu <nal...@ya...> wrote:
> Hi
>
> I read the FAQ, man pages and tried several settings to solve a
> simple problem "how to retain Seen flag when fetching mail with
> fetchmail" and met with complete failure.
>
> The problem is that when I read the mail on the server using
> elm, mailx, or squrrelmail, they all agree on what message is
> previously read and what is not. However, when I fetch the mail
> using fetchmail, those status bits are disappearing. I am
> attaching my .fetchmailrc, the contents of the mailbox before
> the fetchmail, output of "fetchmail -v -v", and the mailbox
> after the mail is fetched. Any help is welcome.

Fetchmail keeps track locally of the email it's fetched.  This is
because fetchmail is *NOT* designed as an MUA, but to download remote
mailboxes.

In short, fetchmail is not designed for what you're trying to do
(though you don't say *why* you're trying to do it).

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

[fetchmail-users] "Seen" status disappears everytime [Resending]

[Ratan N. <nal...@ya...>]

Hi

I read the FAQ, man pages and tried several settings to solve a 
simple problem "how to retain Seen flag when fetching mail with
fetchmail" and met with complete failure.

The problem is that when I read the mail on the server using
elm, mailx, or squrrelmail, they all agree on what message is
previously read and what is not. However, when I fetch the mail
using fetchmail, those status bits are disappearing. I am
attaching my .fetchmailrc, the contents of the mailbox before
the fetchmail, output of "fetchmail -v -v", and the mailbox
after the mail is fetched. Any help is welcome.

Thanks!
Ratan

============== .fetchmairc ===========
set postmaster "ratan"
set bouncemail
set no spambounce
set properties ""

defaults mda "/usr/bin/procmail -d %T"


poll bitter
    plugin "env -u DISPLAY /home/ratan/bin/%h exec
/usr/local/bin/imapd" auth ssh;
    user 'ratan' there is 'ratan' here
    expunge 10
    options fetchall
    mda "cat >> /home/ratan/TEST"

======= mailbox before fetchmail =====
$ cat /var/mail/ratan
>From ra...@cu...  Thu Apr 20 10:03:13 2006
Return-Path: <ra...@cu...>
Received: (from ratan@localhost)
        by bitter.cup.hp.com (8.11.1/8.11.1) id k3KH3D606424
        for ratan; Thu, 20 Apr 2006 10:03:13 -0700 (PDT)
Date: Thu, 20 Apr 2006 10:03:13 -0700 (PDT)
From: Ratan Nalumasu <ra...@cu...>
Message-Id: <200...@bi...>
To: ra...@bi...
Subject: mark this message as seen
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: RO

asdfasdf

>From ra...@cu...  Thu Apr 20 10:03:22 2006
Return-Path: <ra...@cu...>
Received: (from ratan@localhost)
        by bitter.cup.hp.com (8.11.1/8.11.1) id k3KH3Mm06429
        for ratan; Thu, 20 Apr 2006 10:03:22 -0700 (PDT)
Date: Thu, 20 Apr 2006 10:03:22 -0700 (PDT)
From: Ratan Nalumasu <ra...@cu...>
Message-Id: <200...@bi...>
To: ra...@bi...
Subject: NEW message
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

========== fetchmail -v -v =======
$ fetchmail -v -v
fetchmail: 6.2.5.2 querying bitter (protocol auto) at Thu 20 Apr
2006 10:06:13 AM PDT: poll started
fetchmail: 6.2.5.2 querying bitter (protocol IMAP) at Thu 20 Apr
2006 10:06:13 AM PDT: poll started
fetchmail: running env -u DISPLAY /home/ratan/bin/%h exec
/usr/local/bin/imapd (host bitter service 143)
fetchmail: IMAP< * PREAUTH [CAPABILITY IMAP4REV1 LITERAL+ IDLE
NAMESPACE MAILBOX-REFERRALS BINARY UNSELECT SCAN SORT
THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND]
Pre-authenticated user ratan bitter.cup.hp.com IMAP4rev1
2004.352 at Thu, 20 Apr 2006 10:06:17 -0700 (PDT)
fetchmail: IMAP> A0001 CAPABILITY
fetchmail: IMAP< * CAPABILITY IMAP4REV1 LITERAL+ IDLE NAMESPACE
MAILBOX-REFERRALS BINARY UNSELECT SCAN SORT THREAD=REFERENCES
THREAD=ORDEREDSUBJECT MULTIAPPEND SASL-IR LOGIN-REFERRALS
STARTTLS LOGINDISABLED
fetchmail: IMAP< A0001 OK CAPABILITY completed
fetchmail: Protocol identified as IMAP4 rev 1
fetchmail: selecting or re-polling default folder
fetchmail: IMAP> A0002 SELECT "INBOX"
fetchmail: IMAP< * 0 EXISTS
fetchmail: IMAP< * 2 EXISTS
fetchmail: IMAP< * NO Mailbox vulnerable - error creating
/var/mail/ratan.lock: No such file or directory
fetchmail: IMAP< * 0 RECENT
fetchmail: IMAP< * OK [UIDVALIDITY 1124412405] UID validity
status
fetchmail: IMAP< * OK [UIDNEXT 25193] Predicted next UID
fetchmail: IMAP< * FLAGS (\Answered \Flagged \Deleted \Draft
\Seen)
fetchmail: IMAP< * OK [PERMANENTFLAGS (\* \Answered \Flagged
\Deleted \Draft \Seen)] Permanent flags
fetchmail: IMAP< * OK [UNSEEN 2] first unseen message in
/home/ratan/mail/mbox
fetchmail: IMAP< A0002 OK [READ-WRITE] SELECT completed
fetchmail: 2 messages waiting after first poll
fetchmail: IMAP> A0003 EXPUNGE
fetchmail: IMAP< A0003 OK No messages deleted, so no update
needed
fetchmail: 2 messages waiting after expunge
2 messages for ratan at bitter.
fetchmail: IMAP> A0004 FETCH 1:2 RFC822.SIZE
fetchmail: IMAP< * 1 FETCH (RFC822.SIZE 491)
fetchmail: IMAP< * 2 FETCH (RFC822.SIZE 467)
fetchmail: IMAP< A0004 OK FETCH completed
fetchmail: IMAP> A0005 FETCH 1 RFC822.HEADER
fetchmail: IMAP< * 1 FETCH (RFC822.HEADER {481}
reading message ra...@bi...:1 of 2 (481 header
octets)
About to rewrite Return-Path: <ra...@cu...>
Rewritten version is Return-Path: <ra...@cu...>

About to rewrite From: Ratan Nalumasu <ra...@cu...>
Rewritten version is From: Ratan Nalumasu <ra...@cu...>

About to rewrite To: ra...@bi...
Rewritten version is To: ra...@bi...

fetchmail: about to deliver with: cat >> /home/ratan/TEST
#
fetchmail: IMAP< )
fetchmail: IMAP< A0005 OK FETCH completed
fetchmail: IMAP> A0006 FETCH 1 BODY.PEEK[TEXT]
fetchmail: IMAP< * 1 FETCH (BODY[TEXT] {10}
 (10 body octets) *
fetchmail: IMAP< )
fetchmail: IMAP< A0006 OK FETCH completed
 flushed
fetchmail: IMAP> A0007 STORE 1 +FLAGS (\Seen \Deleted)
fetchmail: IMAP< * 1 FETCH (FLAGS (\Seen \Deleted))
fetchmail: IMAP< A0007 OK STORE completed
fetchmail: IMAP> A0008 FETCH 2 RFC822.HEADER
fetchmail: IMAP< * 2 FETCH (RFC822.HEADER {467}
reading message ra...@bi...:2 of 2 (467 header
octets)
About to rewrite Return-Path: <ra...@cu...>
Rewritten version is Return-Path: <ra...@cu...>

About to rewrite From: Ratan Nalumasu <ra...@cu...>
Rewritten version is From: Ratan Nalumasu <ra...@cu...>

About to rewrite To: ra...@bi...
Rewritten version is To: ra...@bi...

fetchmail: about to deliver with: cat >> /home/ratan/TEST
#
fetchmail: IMAP< )
fetchmail: IMAP< A0008 OK FETCH completed
fetchmail: IMAP> A0009 FETCH 2 BODY.PEEK[TEXT]
fetchmail: IMAP< * 2 FETCH (BODY[TEXT] "")
 (0 body octets)
fetchmail: IMAP< A0009 OK FETCH completed
 flushed
fetchmail: IMAP> A0010 STORE 2 +FLAGS (\Seen \Deleted)
fetchmail: IMAP< * 2 FETCH (FLAGS (\Seen \Deleted))
fetchmail: IMAP< A0010 OK STORE completed
fetchmail: selecting or re-polling default folder
fetchmail: IMAP> A0011 EXPUNGE
fetchmail: IMAP< * 1 EXPUNGE
fetchmail: IMAP< * 1 EXPUNGE
fetchmail: IMAP< * 0 EXISTS
fetchmail: IMAP< * 0 RECENT
fetchmail: IMAP< A0011 OK Expunged 2 messages
fetchmail: 0 messages waiting after re-poll
fetchmail: IMAP> A0012 LOGOUT
fetchmail: IMAP< * BYE bitter.cup.hp.com IMAP4rev1 server
terminating connection
fetchmail: IMAP< A0012 OK LOGOUT completed
fetchmail: 6.2.5.2 querying bitter (protocol IMAP) at Thu 20 Apr
2006 10:06:15 AM PDT: poll completed
fetchmail: 6.2.5.2 querying bitter (protocol auto) at Thu 20 Apr
2006 10:06:15 AM PDT: poll completed
fetchmail: not swapping UID lists, no UIDs seen this query
fetchmail: Deleting fetchids file.
fetchmail: normal termination, status 0
fetchmail: Deleting fetchids file.

======= contents of /home/ratan/TEST file as a result of
fetchmail ========

$ cat TEST
Return-Path: <ra...@cu...>
Received: from bitter.cup.hp.com [15.13.188.97]
        by localhost with IMAP (fetchmail-6.2.5.2)
        for ratan@localhost (single-drop); Thu, 20 Apr 2006
10:06:15 -0700 (PDT)
Received: (from ratan@localhost)
        by bitter.cup.hp.com (8.11.1/8.11.1) id k3KH3D606424
        for ratan; Thu, 20 Apr 2006 10:03:13 -0700 (PDT)
Date: Thu, 20 Apr 2006 10:03:13 -0700 (PDT)
From: Ratan Nalumasu <ra...@cu...>
Message-Id: <200...@bi...>
To: ra...@bi...
Subject: mark this message as seen
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

asdfasdf
Return-Path: <ra...@cu...>
Received: from bitter.cup.hp.com [15.13.188.97]
        by localhost with IMAP (fetchmail-6.2.5.2)
        for ratan@localhost (single-drop); Thu, 20 Apr 2006
10:06:15 -0700 (PDT)
Received: (from ratan@localhost)
        by bitter.cup.hp.com (8.11.1/8.11.1) id k3KH3Mm06429
        for ratan; Thu, 20 Apr 2006 10:03:22 -0700 (PDT)
Date: Thu, 20 Apr 2006 10:03:22 -0700 (PDT)
From: Ratan Nalumasu <ra...@cu...>
Message-Id: <200...@bi...>
To: ra...@bi...
Subject: NEW message
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

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

"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

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

[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

[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] Getting only messages older than X days

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

Arik Funke <ari...@gm...> writes:

> The idea is to use fetchmail to create an archive of my various email
> accounts at a central location... but only archive emails that have been
> on the respective account for some time, such as to give me time to
> delete spam and unwanted mail with my email client before archiving.

fetchmail does not support such age-based operations (yet).

-- 
Matthias Andree

Re: [fetchmail-users] Getting only messages older than X days

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

On 4/14/06, Arik Funke <ari...@gm...> wrote:
> Hello together,
>
> does anybody know if it is possible to use fetchmail to get only
> messages that are older than X days?

No.

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

[fetchmail-users] Getting only messages older than X days

[Arik F. <ari...@gm...>]

Hello together,

does anybody know if it is possible to use fetchmail to get only 
messages that are older than X days?

The idea is to use fetchmail to create an archive of my various email 
accounts at a central location... but only archive emails that have been 
on the respective account for some time, such as to give me time to 
delete spam and unwanted mail with my email client before archiving.

Cheers,
Arik