On Jan 21, 2004, at 2:09 PM, Pat Lashley wrote:
Another advantage of Exim is that if using LMTPd over TCP/IP for
Cyrus delivery, you can use a 'verify recipient/callout' ACL to
both test for the existance of virtual users and also to detect
Over Quota situations and issue a temporary failure code
--On Wednesday, January 21, 2004 16:30:54 -0500 Scott Adkins <[EMAIL PROTECTED]> wrote:
Actually, the aliases for postmaster and mailer-daemon are as follows:
postmaster: root+postmaster
mailer-daemon: root+mailer-daemon
The problem is that the mail isn't going *to* Mailer-Daemon, it is
comin
--On Wednesday, January 21, 2004 12:52 PM -0800 Pat Lashley
<[EMAIL PROTECTED]> wrote:
--On Wednesday, January 21, 2004 14:22:33 -0600 Robert Covell
<[EMAIL PROTECTED]> wrote:
I too would be interested in the question about "abnormal amount of
emails to postmaster". We get about 15K a day of the
-- Scott Adkins <[EMAIL PROTECTED]> is rumored to have mumbled on Mittwoch,
21. Januar 2004 16:30 Uhr -0500 regarding RE: postmaster mail:
The problem is that the mail isn't going *to* Mailer-Daemon, it is
coming *from* Mailer-Daemon *to* postmaster. So, setting the alias to
mailer-d
On Wed, 21 Jan 2004, Scott Adkins wrote:
> What have you guys done? I am more interested in the larger email
> system, ones receiving on the order of 500k+ messages a day. Is it
> abnormal to see such a large volume of postmaster mail like this? Have
> any of you developed a sieve script that w
--On Wednesday, January 21, 2004 14:22:33 -0600 Robert Covell <[EMAIL PROTECTED]> wrote:
I too would be interested in the question about "abnormal amount of emails
to postmaster". We get about 15K a day of these and just recently started
to pipe them into /dev/null. It is more of a burden to del
I too would be interested in the question about "abnormal amount of emails
to postmaster". We get about 15K a day of these and just recently started
to pipe them into /dev/null. It is more of a burden to delete them
manually. Anyone else have high postmaster email counts?
Sincerely,
Robert T.