Strange mail problem

Tue Dec 13 11:39:12 UTC 2016

John:

I still don't understand why you need to stop and start fetchmail, let
alone why you need three instances to monitor three accounts.

You can easily configure your  .fetchmailrc to source multiple accounts. If you want polling at different time intervals for each, you can configure that in the stanza for each account. You can even poll securely using ssh. Here's an old .fetchmailrc of mine that illustrates all this:

set daemon 20

#Retrieve from opera:
poll mail.rednote.net
proto imap
plugin "ssh %h /usr/libexec/dovecot/imap"
auth ssh
fetchall
idle

#Retrieve from Octothorp:
poll speakup.octothorp.org
interval 360
proto imap
plugin "ssh %h /usr/libexec/dovecot/imap"
auth ssh
fetchall

I no longer use anything like the above, because I have all my mail
going to my one machine, and I find it most convenient to ssh into it to
read mail whether I'm in my home office or on the road with my laptop.
But, if I did have multiple accounts, I would slirp in my mail as per
the above.

If you look at the man page for fetchmail you'll note the next step is
delivery to port 25 on your local machine. That's were your smtp comes
in--which you haven't mentioned, as I recall. Am I wrong? What's your
smtp application?

The man page for fetchmail also includes some very helpful debugging
info. It's one of the better man pages, imo.

Your smtp agent brings  procmail into the act to deliver mail per your
instructions in .procmailrc to deliver mail per your instructions in
.procmailrc, Here you can similarly
configure procmail to deliver to a single mailbox, or individual
mailboxes, or some combination thereof.

For example, I have procmail recipes that deliver all my W3C list mail
into a single mailbox for quick tracking of what's going on. This is a
lot of mail, and it's sometimes convenient to look at each list
separately. procmail does that for me. Let me know if you'd like example
recipes.

Lastly, there's mutt. In my setup this is one place where I do launch
multiple instances of mutt. I actually do it using screen with 10 open
terminals that I access with a Ctrl-A+N where N is a digit, 0-9. In each
of those screen terminal I launch mutt on another mailbox. That gives me
fast switching among the mbox views I use most frequently--and, yes, I
do have 10 of them.

 hth

 Janina

John J. Boyer writes:
> Hi Janina, Tim and Geoff,
> 
> I am using scripts because I have three email accounts. I set them up many rears ago. They worked fine until I installed 
> Debian on my new machine a couple of months ago. Each has its own fetchmailrc and muttrc. This may not be the best way 
> to do things, but it was working. The script for this address is:
> 
> fetchmail -f as-fetchmailrc
> mutt -F as-muttrc
> killall fetchmail
> 
> The as-fetchmailrc file sets fetchmail to daemon mode. I am uising the default mail format, which I suppose is mbox.
> 
> This address receives a lot of mail. Mutt gets the first ten if there are more. Mailq shows that the rest are in the 
> queue. They are delivered in about half an hour. This is not a mutt problem, because if there are a hundred messages in 
> the queue it will handle them once they are placed in /var/mail/president 
> 
> Thanks,
> John
> 
> On Sat, Dec 10, 2016 at 05:29:37PM +0000, Geoff Shang wrote:
> > On Fri, 9 Dec 2016, John J. Boyer wrote:
> > 
> > >I am using the latest Debian at the command line. For email I use fetchmail, procmail, mutt and msmtp. I have scripts
> > >that call fetchmail in daemon mode and then call mutt. Fetchmail is then killed. The weird thing is that if there are
> > >more than 10 messages I can
> > >see only the first 10. The others show up many minutes later as new mail. What causes this and how can it be fixed?
> > 
> > Like others have said, I don't know why you don't run Fetchmail in daemon
> > mode and just leve it running, but each to his own.
> > 
> > I suspect you might be having issues with your SMTP server.  I saw this
> > issue when I used Fetchmail.  The SMTP server would get all the messages,
> > but would only send on so many.
> > 
> > You can see if this is the issue by running
> > 
> > mailq
> > 
> > once you've received the first batch of messages.  If there are others in
> > the queue, this is the issue.  The queue will need to be flushed, either
> > manually or the next time the server decies to do it, before you will see
> > your messages.
> > 
> > It's so long since I used this configuration that I can't remember what I
> > did about this, and in any case any solution would be SMTP server specific.
> > 
> > I know I used exim (the Debian default) but I don't remember what I did, and
> > I would use Postfix nowadays if I were to do this again.
> > 
> > Nowadays I just do IMAP directly to the server which is IMHO much more
> > efficient.
> > 
> > sorry I can't remember the specifics but this might help narrow down your
> > problem.
> > 
> > Geoff.
> > 
> > _______________________________________________
> > Blinux-list mailing list
> > Blinux-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/blinux-list
> 
> -- 
> John J. Boyer, President
> AbilitiesSoft, Inc.
> Email: john.boyer at abilitiessoft.org
> website: http://www.abilitiessoft.org
> Status: 501(C)(3) NONPROFIT
> Location: Madison, Wisconsin, USA
> Mission: developing assistive technology software and providing STEM services 
>         that are available at no cost
> 
> 
> _______________________________________________
> Blinux-list mailing list
> Blinux-list at redhat.com
> https://www.redhat.com/mailman/listinfo/blinux-list

-- 

Janina Sajka,	Phone:	+1.443.300.2200
			sip:janina at asterisk.rednote.net
		Email:	janina at rednote.net

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Accessible Platform Architectures	http://www.w3.org/wai/apa