Each method of fetch is located in Kernel/System/MailAccount/ (eg, POP3.pm)

For POP3.pm, for instance, a $FetchCount is incremented and compared with
$MaxPopEmailSession, which is either the value of ConfigObject
PostMasterReconnectMessage OR 20, if the former does not exist. It does, in
Ticket, Core::PostMaster in SysConfig because it's required and valid and
default 20, with a Regex filter of between 1 and 3 digits of 0-9
: Regex="^[0-9]{1,3}$" (source: Kernel/Config/Ticket.xml) so, in theory,
the maximum value herein is 999.

In, "what does all that mean?" vernacular: Change it in SysConfig.




On Tue, May 6, 2014 at 4:37 PM, Mark Campbell <mcampb...@emediatrade.com>wrote:

> I know that this is an old thread, but I'm really only just now revisiting
> this problem, and I've got some additional questions.
>
> I did lookup on how to use procmail and not fetch, and I'm not sure how
> well that will work with what we've got, as that will require changes in
> our infrastructure in order to send mail directly to the OTRS server.  Our
> current layout where it's grabbing mail via POP3 is much easier due to
> outsourcing of mail servers, and stuff.
>
> I don't strictly require "realtime" mail reception/processing like what
> the how tos for procmail are touting (the grab-once-per-min cycle will do
> fine), but I am trying to understand why fetchmail only grabs a select few
> emails, instead of all of them, and why this can't be changed (or if it can
> be, how)?  Fetchmail is nearly perfect for the job, if it only would grab
> the whole mailbox, rather than just a few.
>
> Thanks,
>
> --Mark
>
> -----Original Message-----
> From: otrs-boun...@otrs.org [mailto:otrs-boun...@otrs.org] On Behalf Of
> Gerald Young
> Sent: Friday, November 15, 2013 10:08 AM
> To: User questions and discussions about OTRS.
> Subject: Re: [otrs] Question about fetching mail
>
> use procmail and don't fetch.
>
> On Fri, Nov 15, 2013 at 9:59 AM, Mark Campbell <mcampb...@emediatrade.com>
> wrote:
> > So I have a fairly perplexing problem.  I have OTRS 3.1.11 setup on a
> > CentOS6 Virtual Machine, and under our normal email flow (<100
> > messages/day), the system works like a charm.  However, once a month,
> > we hit a spike in emails, to the tune of 10,000 in a day.  Most of
> > these emails are automatically generated by our system, and are merely
> > informational in nature.  I have filters in place to filter them to
> > different queues and in many cases, automatically close them.
> > However, OTRS cannot keep up with downloading them, as apparently
> > every time it fetches email, it only fetches about 10-30 (variable)
> > messages at a time.  Obviously, at 10 minutes in between fetch times,
> > this is almost incomprehensibly slow.  But even at 1 minute fetch
> > intervals, our system can't keep up.  How can I tell it to grab all
> > messages at fetch time?  I've resorted to repeatedly clicking on fetch
> > mail in the admin section under PostMaster Mail Accounts, and even
> > that can take hours when you find that there's 7,000 in the mail queue.
>  Any help would be appreciated.
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Mark Campbell
> >
> > Systems Administrator
> >
> >
> > ---------------------------------------------------------------------
> > OTRS mailing list: otrs - Webpage: http://otrs.org/
> > Archive: http://lists.otrs.org/pipermail/otrs
> > To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
> ---------------------------------------------------------------------
> OTRS mailing list: otrs - Webpage: http://otrs.org/
> Archive: http://lists.otrs.org/pipermail/otrs
> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
> ---------------------------------------------------------------------
> OTRS mailing list: otrs - Webpage: http://otrs.org/
> Archive: http://lists.otrs.org/pipermail/otrs
> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
>
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Reply via email to