fetchmail-users — User questions and discussion

Re: [fetchmail-users] Messages not downloaded

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

Frederic Marchal schrieb:

> What happens is that fetchmail starts retrieving the mails and marks 
> them for deletion as soon as they are delivered to the MDA. Then, at 
> some point, the connection break (usually a timeout) and the server 
> assumes that it should not delete the mails that were marked so (it is 
> the expected behaviour).
> 
> When fetchmail starts the next poll, it sees all the old messages and do 
> not download nor delete them again. Instead it leaves them on the server.

Frédéric,

your observation is correct. I have discussed with Sunil Shetye how we can
mark these messages "deleted" so fetchmail re-does the deletions at the
next cycle, but there have been open issues we haven't answered at the
time, and finding a solution was shelved for various reasons, not the least
of which that it was rather intrusive and had unresolved borderline issues.

One way to contain this with respect to the message count is --expunge
(which forces the deletion to become effective by logging out and in again
for POP3 or sending an EXPUNGE command for IMAP), another one --fetchlimit,
as you suggest (I'm not quoting that) which proceeds to the next server
after a given number of messages downloaded.

The options aren't quite the same and I'm not guaranteeing anything for
older fetchmail version, but either should help with "mail reappearing
after broken connection" issues to some extent.


-- Matthias

Re: [fetchmail-users] Messages not downloaded

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

[resending to list]

David Nash schrieb:

> This is fetchmail release 5.8.17+SSL+NLS

David, if you'd like support from this list, update to 6.3.8 and apply the
patch posted to the security advisory, both available via
http://www.fetchmail.info/

This list cannot currently provide support for older versions - if your
distribution is still supported, ask its vendor for help.

Sorry for the inconvenience, but volunteer support resources are very
limited and nonexistent for all but the current version.

Re: [fetchmail-users] "requires envelope option!"

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

[catching up on email from my vacation...]

Rob MacGregor wrote on Aug 28, 2007:
>   Of course, there may be some value in
> moving to a new format (and providing a tool to migrate) to enforce a
> more logical configuration format.

Heh, I've long disliked the config file format and its implicit structure, 
and long long ago I suggested to ESR that it be changed.  His response 
then was that it was already too established to change and he didn't want 
to have two parsers (for backward compatibility).  Of course he also 
thought his optional English "noise words" thing was a feature rather 
than a bug of the format.

I still think it would be nice to revamp it into some more logical and 
explicitly-structured format in some future major version, but I 
obviously don't have time to work on it.

-- 
==============================|   "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] Messages not downloaded

[Frederic M. <fre...@wo...>]

David Nash a écrit :
> We've been using fetchmail for a few years, but recently noticed that there was a delay of up to 20minutes in receiving messages sent to us from an external email address.  We're using a POP3 multidrop mailbox, and fetchmail passes the retrieved mail to Trestlemail MDA which then drops messages into the correct user's inbox.  It's all worked fine 'til now.  
>  
> I logged on to our domain's webmail service, and noticed that our multidrop inbox had a few thousand messages in it.  I don't think this used to happen, but they've started to collect there.  I cleaned them out, and we started to receive external mail instantaneously (obviously fetchmail was taking time to parse the thousands of messages).
>   
I encounter that problem from time to time. In my case, it always occurs 
after a broken connection.

What happens is that fetchmail starts retrieving the mails and marks 
them for deletion as soon as they are delivered to the MDA. Then, at 
some point, the connection break (usually a timeout) and the server 
assumes that it should not delete the mails that were marked so (it is 
the expected behaviour).

When fetchmail starts the next poll, it sees all the old messages and do 
not download nor delete them again. Instead it leaves them on the server.
>  
> When new mail hits the multi-drop mailbox, its status is 'unread'.  When fetchmail downloads from the multidrop, the mail is removed from the multidrop mailbox, with the exception of some messages where the status changes to 'read' but it is not downloaded.  These are the ones that are building up.  Some of the recipients are genuine users on our system, but many are not.  From what I've been able to monitor, all these messages are SPAM.  I've looked at the headers, and they seem to be pretty much the same as genuine messages, but they have X-IMAIL-SPAM-xxx lines in their header, eg X-IMAIL-SPAM-VALFROM.  
>  
> After all that explanation, I just wondered if fetchmail is looking at these header lines and choosing not to download the messages?  
>   
No header filtering that I'm aware of.
>  
> I'm probably going to look at the 'flush' parameter to automatically delete them, once I've monitored it for a wee while to make sure that every message affected is genuinely SPAM.  I don't really want to change fetchmail versions if I can help it!  
>   
You cannot assumes they are all spams but you may assume they were all 
delivered some time in the past. When I notice that a lot of mails are 
left on the server, I just turn the 'flush' option on for one poll and 
then I disable it for normal usage.

To reduce the likelihood of leaving a lot of mails on the server if the 
connection break late in the transaction, I set fetchlimit to 500 mails. 
With that option, fetchmail closes the POP3 connection after retrieving 
500 mails and the server deletes at least those mails.

Frederic

[fetchmail-users] Messages not downloaded

[David N. <na...@ma...>]

We've been using fetchmail for a few years, but recently noticed that there was a delay of up to 20minutes in receiving messages sent to us from an external email address.  We're using a POP3 multidrop mailbox, and fetchmail passes the retrieved mail to Trestlemail MDA which then drops messages into the correct user's inbox.  It's all worked fine 'til now.  
 
I logged on to our domain's webmail service, and noticed that our multidrop inbox had a few thousand messages in it.  I don't think this used to happen, but they've started to collect there.  I cleaned them out, and we started to receive external mail instantaneously (obviously fetchmail was taking time to parse the thousands of messages).
 
When new mail hits the multi-drop mailbox, its status is 'unread'.  When fetchmail downloads from the multidrop, the mail is removed from the multidrop mailbox, with the exception of some messages where the status changes to 'read' but it is not downloaded.  These are the ones that are building up.  Some of the recipients are genuine users on our system, but many are not.  From what I've been able to monitor, all these messages are SPAM.  I've looked at the headers, and they seem to be pretty much the same as genuine messages, but they have X-IMAIL-SPAM-xxx lines in their header, eg X-IMAIL-SPAM-VALFROM.  
 
After all that explanation, I just wondered if fetchmail is looking at these header lines and choosing not to download the messages?  
 
I'm probably going to look at the 'flush' parameter to automatically delete them, once I've monitored it for a wee while to make sure that every message affected is genuinely SPAM.  I don't really want to change fetchmail versions if I can help it!  
 
Output of fetchmail -V is:
 
This is fetchmail release 5.8.17+SSL+NLS
Linux scoms1.xxxxx.co.uk 2.4.13 #1 Thu Oct 31 02:32:23 EST 2002 i686 unknown
Taking options from command line and /.fetchmailrc
Poll interval is 300 seconds
Idfile is //.fetchids
Fetchmail will forward misaddressed multidrop messages to postmaster.
Options for retrieving from xx...@xx...@xxx.net:
  True name of server is xxx.net.
  Protocol is POP3.
  All available authentication methods will be tried.
  Server nonresponse timeout is 300 seconds (default).
  Default mailbox selected.
  All messages will be retrieved (--all on).
  Fetched messages will not be kept on the server (--keep off).
  Old messages will not be flushed before message retrieval (--flush off).
  Rewrite of server-local addresses is enabled (--norewrite off).
  Carriage-return stripping is enabled (stripcr on).
  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)
  Messages will be delivered with "~/trestlemail/bin/trestlemail ~/trestlemail/trestlemail.rc -F %F -- %T".
  Recognized listener spam block responses are: 571 550 501 554
  Multi-drop mode: 1 local name(s) recognized.
  DNS lookup for multidrop addresses is enabled.
  Server aliases will be compared with multidrop addresses by name.
  Envelope header is assumed to be: Received
  Local domains: xxxx.co.uk
  No UIDs saved from this host.
 
Thanks 
 
David

Me

Re: [fetchmail-users] fetchmail with msmtp as mda

[Neal B. <ndb...@gm...>]

On Wednesday 29 August 2007, Rob MacGregor wrote:
> On 8/29/07, Neal Becker <ndb...@gm...> wrote:
> > I'm using fetchmail with msmtp as mda:
> >
> > poll host proto imap user me password ... mda "/usr/bin/msmtp -i -f %F
> > nb...@nb..."
> >
> > Problem is:
> >
> > Aug 29 11:48:14 host=10.4.0.1 tls=off auth=off from=<>
> > recipients=nb...@nb... smtpstatus=501 smtpmsg='501 <<>>:
> > missing or malformed local part' errormsg='envelope from address <> not
> > accepted by the server' exitcode=EX_DATAERR
> >
> > These same messages just keep accumulating. Every time fetchmail runs, it
> > tries again the same deliveries. How do I teach it these are permanent
> > failures?
>
> I suspect you need to ensure that msmtp returns a status of zero for
> permanent failures (see the MDA option in the man page).
>
> Of course, you're failing to comply with the RFCs by refusing <> as a
> sender :)


Acutally, it now appears the reason for this is that exim was set to:
 require verify        = sender

which is the default.

According to exim spec:
  require verify                     = sender
This statement requires the sender address to be verified before any subsequent 
ACL statement can be
used. If verification fails, the incoming recipient address is refused.

Re: [fetchmail-users] fetchmail with msmtp as mda

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

On 8/29/07, Neal Becker <ndb...@gm...> wrote:
> I'm using fetchmail with msmtp as mda:
>
> poll host proto imap user me password ... mda "/usr/bin/msmtp -i -f %F
> nb...@nb..."
>
> Problem is:
>
> Aug 29 11:48:14 host=10.4.0.1 tls=off auth=off from=<>
> recipients=nb...@nb... smtpstatus=501 smtpmsg='501 <<>>:
> missing or malformed local part' errormsg='envelope from address <> not
> accepted by the server' exitcode=EX_DATAERR
>
> These same messages just keep accumulating. Every time fetchmail runs, it
> tries again the same deliveries. How do I teach it these are permanent
> failures?

I suspect you need to ensure that msmtp returns a status of zero for
permanent failures (see the MDA option in the man page).

Of course, you're failing to comply with the RFCs by refusing <> as a sender :)

-- 
                 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] fetchmail with msmtp as mda

[Neal B. <ndb...@gm...>]

I'm using fetchmail with msmtp as mda:

poll host proto imap user me password ... mda "/usr/bin/msmtp -i -f %F
nb...@nb..."

Problem is:

Aug 29 11:48:14 host=10.4.0.1 tls=off auth=off from=<>
recipients=nb...@nb... smtpstatus=501 smtpmsg='501 <<>>:
missing or malformed local part' errormsg='envelope from address <> not
accepted by the server' exitcode=EX_DATAERR

These same messages just keep accumulating.  Every time fetchmail runs, it
tries again the same deliveries.  How do I teach it these are permanent
failures?

Re: [fetchmail-users] "requires envelope option!"

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

On 8/28/07, Matthias Andree <mat...@gm...> wrote:
>
> I've long since pondered requiring an explicit multidrop keyword in the
> next major fetchmail version, and complaining about multiple destination
> addresses without that magic "multidrop" keyword.
>
> While fetchmail's implicit "understanding" of the verbose rcfiles may be
> useful, I more often than not think that fetchmail does far too many things
> automatically under the hood -- and personally I detest such kind of
> surprise...

That's not a bad idea, presumably in the user section, maybe
"multidrop user" vs "user" (or explicitly "singledrop user")?  Of
course, you could (ab)use the Envelope option that way - without it
the mailbox is singledrop and multiple recipients generates an error.

Mind you if you're going down the route of re-working the parsing
logic how about moving the SSL options from the user section to the
server section, which IMO makes far more sense (after all, the
fingerprint is per-server).  Of course, there may be some value in
moving to a new format (and providing a tool to migrate) to enforce a
more logical configuration format.

-- 
                 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] "requires envelope option!"

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

Rob MacGregor schrieb:
> On 8/27/07, Anne Wilson <can...@go...> wrote:
> <---SNIP--->
>> Now I understand, and also why I don't have the problem on my account.  When I
>> set up his I did go back to the man page to refresh my memory.  I
>> misunderstood the entry '-a | --all | (since v6.3.3) --fetchall', reading it,
>> actually in reverse.  Instead of --fetchall, as in my accounts, I used what I
>> thought I had seen to be the preferred '-a'.  Duh!
> 
> Actually, it's worse than that (but you're helping show we need a
> re-write of the manual).  The entries that begin with a hyphen (-a,
> --all, --fetchall) are all command line options.  The only one valid
> in the .fetchmailrc is the keyword (fetchall).  The manual doesn't
> make the distinction terribly clear (it's mentioned only in passing).
> 

I've long since pondered requiring an explicit multidrop keyword in the
next major fetchmail version, and complaining about multiple destination
addresses without that magic "multidrop" keyword.

While fetchmail's implicit "understanding" of the verbose rcfiles may be
useful, I more often than not think that fetchmail does far too many things
automatically under the hood -- and personally I detest such kind of
surprise...

Best
Matthias

Re: [fetchmail-users] Fetchmail error "requires envelope option"

[Anne W. <can...@go...>]

On Tuesday 28 Aug 2007, Matthias Andree wrote:
> Rob MacGregor schrieb:
> > Hey, at least you've learned to check the destination of last resort.
> > It's something that's worth checking regularly and, along with your
> > mail log, is something worth checking any time things seem to be going
> > wrong.
>
> A general hint is to consider maildrop http://www.courier-mta.org/maildrop/
> as a filtering engine that is much easier to get working properly than
> procmail.
>
> It's more conservative than procmail in that it will simply defer all mail
> on syntax errors in the file, or defer particular messages (pushing them
> back to the queue where you'll see them with mailq(1)) on delivery errors
> -- rather than dumping mail to a random place that procmail would call safe
> but one never checks in a whole lifetime...
>
> There are several design decisions in procmail that I have called and do
> still call stupid, to the outrage of the procmail maintainers who call this
> freedom of choice (which maildrop also offers BTW).

Points taken.  As I only administer a home LAN, and that now simpler than it 
used to be, I went for what seemed to be the most common choice - and 
therefore offering best support. :-)  I'm falling behind in things that are 
started and need completing, so I don't want to change at this moment.  When 
things get quieter I'll read up and see whether the change is right for me.

> One man's meat is another man's poison.

Absolutely.  I appreciate the help given by all.

Anne

Re: [fetchmail-users] Fetchmail error "requires envelope option"

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

Rob MacGregor schrieb:

> Hey, at least you've learned to check the destination of last resort.
> It's something that's worth checking regularly and, along with your
> mail log, is something worth checking any time things seem to be going
> wrong.

A general hint is to consider maildrop http://www.courier-mta.org/maildrop/
as a filtering engine that is much easier to get working properly than
procmail.

It's more conservative than procmail in that it will simply defer all mail
on syntax errors in the file, or defer particular messages (pushing them
back to the queue where you'll see them with mailq(1)) on delivery errors
-- rather than dumping mail to a random place that procmail would call safe
but one never checks in a whole lifetime...

There are several design decisions in procmail that I have called and do
still call stupid, to the outrage of the procmail maintainers who call this
freedom of choice (which maildrop also offers BTW).
One man's meat is another man's poison.

Re: [fetchmail-users] Are my messages being blocked?

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

Gerard Seibert schrieb:

> For the record, I reiterate that her problem exists due to her
> reliance on a substandard web email system.

Record taken. Could we kindly now return to fetchmail affairs and let the
$LARGE_COMMERCIAL_MAIL_SITE_THAT_SNIFFS_YOUR_PERSONAL_MATTERS
advocacy rest for a while?

We know the large sites violate standards so they can tailor things to
their business models and other policies, and we're usually not happy about
that -- but this discussion has long since trodden off fetchmail paths.

Thank you.

Re: [fetchmail-users] "requires envelope option!"

[Anne W. <can...@go...>]

On Monday 27 Aug 2007, Rob MacGregor wrote:
> On 8/27/07, Anne Wilson <can...@go...> wrote:
> <---SNIP--->
>
> > Now I understand, and also why I don't have the problem on my account. 
> > When I set up his I did go back to the man page to refresh my memory.  I
> > misunderstood the entry '-a | --all | (since v6.3.3) --fetchall', reading
> > it, actually in reverse.  Instead of --fetchall, as in my accounts, I
> > used what I thought I had seen to be the preferred '-a'.  Duh!
>
> Actually, it's worse than that (but you're helping show we need a
> re-write of the manual).  The entries that begin with a hyphen (-a,
> --all, --fetchall) are all command line options.  The only one valid
> in the .fetchmailrc is the keyword (fetchall).  The manual doesn't
> make the distinction terribly clear (it's mentioned only in passing).

Well, I do have my uses :-)  Glad you got something useful out of it.

Anne

Re: [fetchmail-users] "requires envelope option!"

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

On 8/27/07, Anne Wilson <can...@go...> wrote:
<---SNIP--->
> Now I understand, and also why I don't have the problem on my account.  When I
> set up his I did go back to the man page to refresh my memory.  I
> misunderstood the entry '-a | --all | (since v6.3.3) --fetchall', reading it,
> actually in reverse.  Instead of --fetchall, as in my accounts, I used what I
> thought I had seen to be the preferred '-a'.  Duh!

Actually, it's worse than that (but you're helping show we need a
re-write of the manual).  The entries that begin with a hyphen (-a,
--all, --fetchall) are all command line options.  The only one valid
in the .fetchmailrc is the keyword (fetchall).  The manual doesn't
make the distinction terribly clear (it's mentioned only in passing).

-- 
                 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] Fetchmail error "requires envelope option"

[Anne W. <can...@go...>]

On Monday 27 Aug 2007, Rob MacGregor wrote:
> [ Sent to the list so others know what happened ]
>
> On 8/27/07, Anne Wilson <can...@go...> wrote:
> > Mystery solved.  It was not being blocked by the list, nor by googlemail.
> >  It was being forwarded to me, as it should be.  However, the problem was
> > a recently added procmail recipe, obviously faulty.  When procmail
> > encounters a problem that confuses it, it puts the messages 'in a safe
> > place'.  I have just found the messages with another 100 or so, to be
> > sorted through. Thankfully, the fetchmail recipe was the only one
> > following the faulty one, or there could have been thousands.
> >
> > Apologies to all for wasting bandwidth.  Now to address the problem.
>
> Hey, at least you've learned to check the destination of last resort.
> It's something that's worth checking regularly and, along with your
> mail log, is something worth checking any time things seem to be going
> wrong.
>
This happened to me just once before, about three years ago.  I had looked for 
the missing emails in what I remembered to be the place I found them last 
time, but things have moved on :-)

> It's also worth saying that any time there are problems with mail
> to/from a list it's worth checking any archive of that list to see if
> mail is reaching it, and if others are replying.  It's also worth
> trying contacting the list administrators via the -owner address (in
> this case fetchmail-users-owner@), which you did indirectly do in this
> case ;)

If the faulty recipe had been earlier in the queue, I'd have realised that 
messages were missing from many folders, and found the problem much quicker.  
Just the way it goes, I guess.  I hadn't thought of checking the archives, 
though, and that's a really stupid oversight.

Anne

Re: [fetchmail-users] "requires envelope option!"

[Anne W. <can...@go...>]

On Monday 27 Aug 2007, Rob MacGregor wrote:
> On 8/27/07, Anne Wilson <can...@go...> wrote:
> > As far as I know, this is what I'm doing.  I run fetchmail as anne, and
> > all messages are delivered to me.  On separate cron jobs, fetchmail runs
> > as david, and all mail is delivered to him.  Isn't that singledrop-mode?
>
> It is, though fetchmail doesn't agree with you :)
>
> > For David's mail - mine doesn't bring the problem\;
> >
> > set logfile = /home/david/fetchmail.log
> >
> > poll pop3.mailbox.co.uk with proto pop3
> >         user "xxxxxx.xxxx"
> >         pass "xxxx"
> >         is david -a
>
> Ok, what's with the command line argument after "david"?  If you mean
> fetchall then you have to use fetchall.  Currently fetchmail is
> expecting to deliver to 2 accounts: "david" and "-a".
>
Now I understand, and also why I don't have the problem on my account.  When I 
set up his I did go back to the man page to refresh my memory.  I 
misunderstood the entry '-a | --all | (since v6.3.3) --fetchall', reading it, 
actually in reverse.  Instead of --fetchall, as in my accounts, I used what I 
thought I had seen to be the preferred '-a'.  Duh!

> > Sufficiently obscured for spam, I think:
> >
> > Return-Path: <con...@e2...>
> >  X-Original-To: david@localhost
> >  Delivered-To: da...@lo...main
>
> If you were doing multi-drop you'd use the envelope "Delivered-To"

Hopefully, having altered fetchmailrc, I shouldn't be seeing the problem 
again, but I'll mark this message up for reference, in case I need it later.

Thanks for help and patience.

Anne

Re: [fetchmail-users] Fetchmail error "requires envelope option"

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

[ Sent to the list so others know what happened ]

On 8/27/07, Anne Wilson <can...@go...> wrote:
>
> Mystery solved.  It was not being blocked by the list, nor by googlemail.  It
> was being forwarded to me, as it should be.  However, the problem was a
> recently added procmail recipe, obviously faulty.  When procmail encounters a
> problem that confuses it, it puts the messages 'in a safe place'.  I have
> just found the messages with another 100 or so, to be sorted through.
> Thankfully, the fetchmail recipe was the only one following the faulty one,
> or there could have been thousands.
>
> Apologies to all for wasting bandwidth.  Now to address the problem.

Hey, at least you've learned to check the destination of last resort.
It's something that's worth checking regularly and, along with your
mail log, is something worth checking any time things seem to be going
wrong.

It's also worth saying that any time there are problems with mail
to/from a list it's worth checking any archive of that list to see if
mail is reaching it, and if others are replying.  It's also worth
trying contacting the list administrators via the -owner address (in
this case fetchmail-users-owner@), which you did indirectly do in this
case ;)

-- 
                 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] "requires envelope option!"

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

On 8/27/07, Anne Wilson <can...@go...> wrote:
>
> As far as I know, this is what I'm doing.  I run fetchmail as anne, and all
> messages are delivered to me.  On separate cron jobs, fetchmail runs as
> david, and all mail is delivered to him.  Isn't that singledrop-mode?

It is, though fetchmail doesn't agree with you :)

> For David's mail - mine doesn't bring the problem\;
>
> set logfile = /home/david/fetchmail.log
>
> poll pop3.mailbox.co.uk with proto pop3
>         user "xxxxxx.xxxx"
>         pass "xxxx"
>         is david -a

Ok, what's with the command line argument after "david"?  If you mean
fetchall then you have to use fetchall.  Currently fetchmail is
expecting to deliver to 2 accounts: "david" and "-a".

> Sufficiently obscured for spam, I think:
>
> Return-Path: <con...@e2...>
>  X-Original-To: david@localhost
>  Delivered-To: da...@lo...main

If you were doing multi-drop you'd use the envelope "Delivered-To"

-- 
                 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] Are my messages being blocked?

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

On 8/27/07, Gerard Seibert <ge...@se...> wrote:
>
> 1) Check out this URL:
>
> https://mail.google.com/support/bin/answer.py?answer=10314&topic=1566
>
> Why your quest failed to turn it up is a mystery.

Which isn't the main part of the problem Anne described

> 2) Where is this 'HOTMAIL' documentation? I am not a friend of Hotmail
> as a rule; however, I have experience far greater success with it than
> Google's lame offering. At Least IMHO, it exceeds GMail in it
> fuctionability.

I've seen threads in many places, not least of which includes NANOG.

> For the record, I reiterate that her problem exists due to her
> reliance on a substandard web email system.

It turns out we were both wrong :)

-- 
                 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] Are my messages being blocked?

[Anne W. <can...@go...>]

On Sunday 26 Aug 2007, Gerard Seibert wrote:
> On Sunday August 26, 2007 at 05:10:23 (PM) Anne Wilson wrote:
> > I've been trying for almost two days to get a message through but they
> > never appear.
> >
> > Anne
>
> You do seem to be having a great deal of trouble; however, I am unsure
> as to what you are specifically referring to. All of the messages that
> you have sent have been received. At least it would appear to be so.
> Why do you think they are not?
>
> Are you failing to receive a copy of the message you sent returned to
> you via this group? If that is the problem, and I think it is, and you
> you are using GMail, and your address would indicates that you are,
> then that is your problem. Google had decreed that you do not have
> that right. When you send a message to a forum such as this, Google
> will not place that message in your in-box when it is relayed by the
> forum you sent the message to. It conveniently loses it. This is a
> well know and documented feature(?) of Google's email system.
>
> Might I suggest that you get a real email provider. Why not simply use
> your ISP's email service for starters. In any event, lose GMail. They
> are the worst service around. They even make 'Hotmail' look good.
> Actually, the new version <http://get.live.com/> isn't all that bad
> when compared to GMail.

I do have 'good' email providers - two, in fact.  You are mistaken, too, in 
your comments about gmail.  I always receive, forwarded to me for reading in 
kmail, copies of all messages I send to lists.  The reason I use gmail for 
lists is quite simple - they manage to trap about half of the spam that comes 
through.  Yes, I need to check their spam pages quite often, but there are 
few false-positives - I'd say about one in 200 at most.

Thanks for trying to help, but it wasn't gmail's fault.

Anne

Re: [fetchmail-users] Are my messages being blocked?

[Gerard S. <ge...@se...>]

On Monday August 27, 2007 at 04:40:33 (AM) Rob MacGregor wrote:

> I call this one FUD.
> 
> It isn't either well known, or documented (that I've ever found).  I
> too am on GMail and I've never yet not received any email.  I *have*
> seen quite a few list emails arrive in Junk however, until the system
> is trained.
> 
> Now Hotmail, it *IS* documented that for Hotmail emails that MS view
> as "junk" are often just dropped on the floor.  I've even confirmed
> this myself, more than once.
> 
> The most important things here are:
> 
> 1) Both Anne and I are on GMail, I'm seeing the emails fine
> 2) I've CCd Anne on 2 emails and emailed her direct on 2 - she hasn't
> responded to or seen any of these
> 
> I'm strongly of the opinion that Anne is neglecting to check her Junk
> mail folder.  I'll be trying a non GMail account to contact her later.


How you can conceivably make a connection between the acronym FUD and
the situation at hand is beyond me. Anyway, back to our regularly
scheduled discussion.

1) Check out this URL:

https://mail.google.com/support/bin/answer.py?answer=10314&topic=1566

Why your quest failed to turn it up is a mystery.

2) Where is this 'HOTMAIL' documentation? I am not a friend of Hotmail
as a rule; however, I have experience far greater success with it than
Google's lame offering. At Least IMHO, it exceeds GMail in it
fuctionability.

3) The use of 'recent' in GMail will result in the user receiving a
copy of every message that they send. Are you employing this technique?
If you are not familiar with the 'recent' tag in GMail, Google for it.
If you still cannot find it, contact me.

For the record, I reiterate that her problem exists due to her
reliance on a substandard web email system.


-- 
Gerard

Re: [fetchmail-users] "requires envelope option!"

[Anne W. <can...@go...>]

On Thursday 23 Aug 2007, Rob MacGregor wrote:
> On 8/23/07, Anne Wilson <can...@go...> wrote:
> > Apologies if this is a duplicate, but it's almost 3 hours since I sent
> > it, and I haven't seen it yet.
>
> It is a duplicate.
>
Sorry - explained elsewhere.

> > I'm now fetching my husband's mail, as well as my own (using fetchmail
> > with cron, running as david), but I'm getting:
> >
> > fetchmail: warning: multidrop for pop3.mailbox.co.uk requires envelope
> > option! fetchmail: warning: Do not ask for support if all mail goes to
> > postmaster!
>
> Did you look at the envelope option in the man page?
>
I've read it, but it didn't seem to apply.  See below.

> > This never happens when I collect my mail (fetchmail with cron, running
> > as anne).  Googling hasn't come up with anything useful.  What is this
> > about? Thanks
>
> As Matthias said, you may want to read the fine manual, the section on
> "Use and Abuse of Multidrop" details what you need to do.
>
<quote>
In singledrop-mode, fetchmail assumes that all messages in the user's account 
are intended for a single recipient.
</quote>

As far as I know, this is what I'm doing.  I run fetchmail as anne, and all 
messages are delivered to me.  On separate cron jobs, fetchmail runs as 
david, and all mail is delivered to him.  Isn't that singledrop-mode?

> If you're still confused after consulting the documentation, please
> provide:
>
> 1) Your .fetchmailrc

For David's mail - mine doesn't bring the problem\;

set logfile = /home/david/fetchmail.log

poll pop3.mailbox.co.uk with proto pop3
	user "xxxxxx.xxxx"
	pass "xxxx"
	is david -a

poll zencphosting09.zen.co.uk with proto pop3
	user "xx...@ly..."
	pass "xxxxx"
	sslfingerprint "01:A0:29:54:2F:03:DB:AE:79:8D:B8:B9:BB:9A:1F:9A"
	is david -a

poll pop3.tiscali.co.uk with proto pop3
	user "xx...@ti..."
	pass "xxxx"
	is david -a

> 2) The FULL headers of a sample email (mask email addresses or account
> names if you want, but leave all the lines in)

Sufficiently obscured for spam, I think:

Return-Path: <con...@e2...>
 X-Original-To: david@localhost
 Delivered-To: da...@lo...main
 Received: from david.my.domain (david.my.domain [127.0.0.1])
        by david.my.domain (Postfix) with ESMTP id 5E544C9192
        for <david@localhost>; Tue, 21 Aug 2007 10:30:11 +0100 (BST)
 Envelope-to: dav...@my...main
 Delivery-date: Tue, 21 Aug 2007 10:29:34 +0100
 Received: from zencphosting09.zen.co.uk [82.71.204.15]
        by david.my.domain with POP3 (fetchmail-6.3.8)
        for <david@localhost> (single-drop); Tue, 21 Aug 2007 10:30:11 +0100 
(BST)
 Received: from [212.23.3.230] (port=50776 helo=bastion05.mail.zen.co.uk)
        by zencphosting09.zen.co.uk with esmtp (Exim 4.63)
        (envelope-from <con...@e2...>)
        id 1INQ3K-0007xe-FN
        for dav...@my...main; Tue, 21 Aug 2007 10:29:34 +0100
 Received: from mail174.e2ma.net ([66.179.147.174])
        by bastion05.mail.zen.co.uk with esmtp (Exim 4.63)
        (envelope-from <con...@e2...>)
        id 1INQ3K-0006Cn-2g
        for dav...@my...main; Tue, 21 Aug 2007 09:29:34 +0000
 To: davidxxxx@myotherdomain
 From: "Armitages Garden Centre" <the...@ar...>
 Subject: Confirming your subscription to the Armitages Garden Centre email 
list
 Date: Tue, 21 Aug 2007 04:27:45 -0500
 Message-ID: <0ba...@e2...>
 MIME-Version: 1.0
 Content-Type: text/plain;
 X-Zen-Test-Spam-Score: 11
 X-Zen-Test-Spam-Bar: (+)
 X-Originating-Bastion05-IP: [66.179.147.174]
 X-Envelope-From: con...@e2...
 X-Envelope-To: dav...@my...main
 X-Apparently-To: dav...@my...main
 X-Zen-Loop2: 7b9882177c9c8ff4976e7f923821a659
 Status: R
 X-Status: NC
 X-KMail-EncryptionState: 
 X-KMail-SignatureState: 
 X-KMail-MDN-Sent: 
 X-Length: 2615
 X-UID: 1

Anne

[fetchmail-users] OT, hotmail dumping email, was: Are my messages being blocked?

[M. F. <mfi...@ne...>]

On Mon, Aug 27, 2007 09:40:33 AM +0100, Rob MacGregor
(rob...@gm...) wrote:

> Now Hotmail, it *IS* documented that for Hotmail emails that MS view
> as "junk" are often just dropped on the floor.  I've even confirmed
> this myself, more than once.

Just one note: I always welcome, either here or privately, links to
pages that denounce and document this, especially when the email
server whose message disappear has done everything Hotmail wants from
good email sysadmins.

Thanks,
Marco

Re: [fetchmail-users] Fetchmail incorrect header yahoo

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

Andrew  schrieb:
> Ok guys... I've verified that this isn't a fetchmail issue. It appears 
> to be a freepops issue. However, my questions still stands... Is there a 
> way to force fetchmail to deliver the messages even if there isn't any 
> header information?

Not officially at the moment, since that would only work properly for
singledrop, and because it may make sense to regenerate mandatory headers
in case the SMTP listener doesn't.

But there are more important bugs to address first, and workarounds are
usually low-priority if they intend to work around other server's bugs.

Gentoo however have a patch to let fetchmail continue to ship those
messages, but evidently you're getting whatever your local SMTP/LMTP server
or MDA make of the junk they're given. Some try to normalize, some reject,
you never know until you check the specs, the configuration and everything
else -- Rob is right in that we'd best stuff the remaining shards and
pieces of the message into some kind of plastic bag before shipping them
on, and that requires a lot of work I'm not going to spend on 6.3 which is
essentially "bug fixes only".

Sorry.

Best regards
Matthias