Re: Strange mail problem
Hi Yoshio, Thanks again. I think I can solve the problem now. John On Tue, Dec 13, 2016 at 10:50:55PM -0800, yoshio wrote: > Also, if you just installed a new debian system, the default MTA is exim4. > Try typing "dpkg -l |grep exim", do you see any exim packages listed? > > https://wiki.debian.org/PkgExim4UserFAQ says exim delivers the first > 10 messages and puts the rest in the queue. It suggests making fetchmail > run "exim -q" in the postconnect, or just use procmail to bypass your local > MTA. Just for completeness, https://wiki.debian.org/Exim also exists. > > The exim option smtp_accept_queue_per_connection default value is 10 > > from > http://www.exim.org/exim-html-current/doc/html/spec_html/ch-main_configuration.html > This option limits the number of delivery processes that Exim starts > automatically when receiving messages via SMTP, whether via the daemon or by > the use of -bs or -bS. If the value of the option is greater than zero, and > the number of messages received in a single SMTP session exceeds this number, > subsequent messages are placed on the queue, but no delivery processes are > started. This helps to limit the number of Exim processes when a server > restarts after downtime and there is a lot of mail waiting for it on other > systems. On large systems, the default should probably be increased, and on > dial-in client systems it should probably be set to zero (that is, disabled). > > original source: > https://stackoverflow.com/questions/3914357/problem-with-sending-multiple-mails-per-smtp-connection-with-zend-mail-and-exim/5193004 > > ___ > Blinux-list mailing list > Blinux-list@redhat.com > https://www.redhat.com/mailman/listinfo/blinux-list -- John J. Boyer, President AbilitiesSoft, Inc. Email: john.bo...@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@redhat.com https://www.redhat.com/mailman/listinfo/blinux-list
Re: Strange mail problem
Hi Yoshio,
This looks helpful. All I'm really interested in is why only the first ten
messages are delivered immediately and the
rest sit in the mail queue for what seems like half an hour.
Thanks,
John
On Tue, Dec 13, 2016 at 10:15:21PM -0800, yoshio wrote:
> Hi John,
>
> I have this in my .fetchmailrc
>
>mda "/usr/bin/procmail -d %T"
>
> so fetchmail calls procmail directly, without going through a local smtp
> server.
>
> On a debian system you can look at /usr/share/doc/msmtp/examples -
> in the msmtpq directory, you can find the msmtp-queue command, the -r
> option is "run (flush) mail queue - all mail in queue" - I'm guessing
> this would be helpful (I don't run msmtp myself).
>
> While I have mutt open, and then run fetchmail, sometimes new mail doesn't
> appear until I hit the down arrow on the last message in a mailbox, then
> suddenly the new mail appears.
>
> https://unix.stackexchange.com/questions/138047/mutt-automatically-show-new-mesages#138099
> suggests adding:
>set timeout=30
> to your ~/.muttrc
>
> typing "man muttrc" on debian system shows the timeout default is 600 seconds
> (10 minutes).
>
> >From https://dev.mutt.org/trac/wiki/MuttFaq/Folder
>
> How to make mutt check for new mail more often? What's the difference between
> $timeout and $mail_check?
>
> After every keyboard input mutt updates the status of all folders. To receive
> "New mail in ..." notifications even without needing to press a key, set
> $timeout == time to wait for idle mutt (no key pressed) before the status is
> updated again as if a key were pressed. To avoid too frequent folder access
> (bad connections via NFS or IMAP), set $mail_check == minium time between 2
> scans for new mail (external changes to folders) in case of high keyboard
> activity.
>
> $mail_check < $timeout : scan on next update $timeout < $mail_check :
> update before scan
>
> This means $mail_check < $timeout is more useful, because by the time mutt
> will update, it will also scan for external changes to incorporate them in
> the update.
> How to get informed about new mail?
>
> When new mail arrives, an automatic (no key pressed) "New mail in ..."
> notification is shown at the screen bottom. This happens only in the index
> menu. For manual checking, you can use the buffy-list function which works in
> the pager, index and folder browser. It prints a list of folders with new
> mail. However, it will display an up-to-date list only when the index menu is
> focused. Additionally, you can invoke check-new in the folder browser which
> updates the display ('N' flag for folders with new mail) and also buffy-lists
> folder list.
>
> ___
> Blinux-list mailing list
> Blinux-list@redhat.com
> https://www.redhat.com/mailman/listinfo/blinux-list
--
John J. Boyer, President
AbilitiesSoft, Inc.
Email: john.bo...@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@redhat.com
https://www.redhat.com/mailman/listinfo/blinux-list
Re: Strange mail problem
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 +, 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. > > > > ___
Re: Strange mail problem
On December 12, 2016, John J. Boyer wrote: > 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. Answers to a couple more questions might help track down where things are going slow: Are you running mailq on the mail server or on your local machine? Also, are you running fetchmail in singledrop mode (fetching one address worth of mail) or multidrop mode (receiving remote mail destined for many local recipients)? Are you using fetchmail's "--mda" (or just "-m") option to specify a MDA manually, or is using the default of connecting to port 25 of your localhost and then getting routed around as mail? -tim ___ Blinux-list mailing list Blinux-list@redhat.com https://www.redhat.com/mailman/listinfo/blinux-list
Re: Strange mail problem
In the earlier version of debian you may not have used systemd. That's changed and I expect systemd is lots more picky about memory use. Fortunately, you can put all thrree email accounts into one .fetchmailrc file. If you know how to use sed, you could have sed edit your .fetchmailrc file and comment out the two accounts you don't want to read and uncomment the account you do want to read Those sed commands could go into your scripts for future use too. On Mon, 12 Dec 2016, John J. Boyer wrote: Date: Mon, 12 Dec 2016 11:15:03 From: John J. Boyer <john.bo...@abilitiessoft.org> Reply-To: Linux for blind general discussion <blinux-list@redhat.com> To: Linux for blind general discussion <blinux-list@redhat.com> Subject: Re: Strange mail problem 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 +, 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@redhat.com https://www.redhat.com/mailman/listinfo/blinux-list -- ___ Blinux-list mailing list Blinux-list@redhat.com https://www.redhat.com/mailman/listinfo/blinux-list
Re: Strange mail problem
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 +, 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@redhat.com > https://www.redhat.com/mailman/listinfo/blinux-list -- John J. Boyer, President AbilitiesSoft, Inc. Email: john.bo...@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@redhat.com https://www.redhat.com/mailman/listinfo/blinux-list
Re: Strange mail problem
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@redhat.com https://www.redhat.com/mailman/listinfo/blinux-list
Re: Strange mail problem
In addition to Janina's suggestions, it would also help to know
1) how are you storing mail? In maildir or mbox format?
2) if you look in your local mail directories, is all the mail
there. Determining the number of messages may depend on which format
you're storing it in. For mbox, you should be able to do
grep -c '^From' ${MAIL_STORE}/your_mbox_file
and for the maildir format, you should be able to
find ${MAIL_STORE}/.{cur,new} -type f | wc -l
My main interest would be whether fetchmail is successfully pulling
in the mail but mutt isn't seeing it, or if fetchmail is failing to
bring in all the mail in the first place.
-tim
On December 9, 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?
>
> Thanks,
> John
>
> --
> John J. Boyer, President
> AbilitiesSoft, Inc.
> Email: john.bo...@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@redhat.com
> https://www.redhat.com/mailman/listinfo/blinux-list
___
Blinux-list mailing list
Blinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/blinux-list
Re: Strange mail problem
John: I think you need to provide all more information for any of us to help you here. For instance, let's start with just the fetchmail piece. You mention scripts. I'm not sure why you would use a script for fetchmail. I would expect you'd enable it in daemon mode, probably using systemd, and your ~/.fetchmailrc. Now, if the problem is in fetchmail, you can watch mail being fetched with a command like: fetchmail -avvv Next question regards procmail. Who's handing off to procmail? I presume you have a ~/.procmailrc. If so, enable logging and review the logs to see whether there's a problem in this piece. By the time you get to mutt, all the mail should already be delivered. Mutt is just the user agent for viewing and processing mail for storage or for outbound forwarding. What's your .muttrc look like? John J. Boyer writes: > 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? > > Thanks, > John > > -- > John J. Boyer, President > AbilitiesSoft, Inc. > Email: john.bo...@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@redhat.com > https://www.redhat.com/mailman/listinfo/blinux-list -- Janina Sajka, Phone: +1.443.300.2200 sip:jan...@asterisk.rednote.net Email: jan...@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 Architectureshttp://www.w3.org/wai/apa ___ Blinux-list mailing list Blinux-list@redhat.com https://www.redhat.com/mailman/listinfo/blinux-list
