Prev: SYSERR(root): buildaddr: unknown mailer procmail
Next: host name lookup failure
From: Grant Taylor on 1 Feb 2007 10:48
Alex Moen wrote:
> OK, understood, but that does not answer the question of why the queue files
> never go away, even after the timeout has occurred. Why would those files
> not be deleted after the timeout? If Sendmail would accept that it is
> undeliverable after a time and then give up and delete the files, the
> problem would not exist. Do I not understand something here, or what am I
> missing?

What files are being left in the queue? Do the files start with "Q" or
"q"? Case makes a difference, as one is left behind (in a fashion) by
Sendmail b/c it will not intentionally drop mail that it has accepted
responsibility for. If a file starts with "Q" then the file has been
left there for an administrator to work with.

If you check your mail logs, you may see "Save Mail Panic" (or something
like that), which is Sendmail panicking b/c it has no place to send /
save the mail. I believe this is caused by the situation you are
experiencing.

I have minimized the number of files that Sendmail leaves in the mail
queue by setting up a double bounce address which Sendmail can send such
messages to. Then I can decide what to do with these messages. In your
case, you can route them to /dev/null, or even set up a rule in Sendmail
that causes messages in to that address to be accepted and then
discarded / not delivered.

If you can provide any more information on the files that were left
behind, I might be able to come up with an explanation. I'm sorry you
feel the way that you do about Milters b/c they really are a good thing
and I'd like to help clear the air.



Grant. . . .

From: Alex Moen on 1 Feb 2007 12:02

"Grant Taylor" <gtaylor(a)riverviewtech.net> wrote in message
news:mailman.135.1170344835.28999.comp.mail.sendmail(a)maillists.riverviewtech.net...
> Alex Moen wrote:
>> OK, understood, but that does not answer the question of why the queue
>> files never go away, even after the timeout has occurred. Why would
>> those files not be deleted after the timeout? If Sendmail would accept
>> that it is undeliverable after a time and then give up and delete the
>> files, the problem would not exist. Do I not understand something here,
>> or what am I missing?

> What files are being left in the queue? Do the files start with "Q" or
> "q"? Case makes a difference, as one is left behind (in a fashion) by
> Sendmail b/c it will not intentionally drop mail that it has accepted
> responsibility for. If a file starts with "Q" then the file has been left
> there for an administrator to work with.

Well, the files are all q (lower case), and of course, d (lower case). No
upper case Q's are in the directory.

> If you check your mail logs, you may see "Save Mail Panic" (or something
> like that), which is Sendmail panicking b/c it has no place to send / save
> the mail. I believe this is caused by the situation you are experiencing.

No instances of panic or save in the log files (grep -iw panic
/var/log/maillog ; grep -iw save /var/log/maillog) other than those that are
contained in domain names or e-mail addresses.

> I have minimized the number of files that Sendmail leaves in the mail
> queue by setting up a double bounce address which Sendmail can send such
> messages to. Then I can decide what to do with these messages. In your
> case, you can route them to /dev/null, or even set up a rule in Sendmail
> that causes messages in to that address to be accepted and then discarded
> / not delivered.

This would be a great help, and actually would probably solve the problem.
Is there an example somewhere that explains how to do this? And, what is
the reason that this is not the default behavior?

> If you can provide any more information on the files that were left
> behind, I might be able to come up with an explanation. I'm sorry you
> feel the way that you do about Milters b/c they really are a good thing
> and I'd like to help clear the air.
>
>
>
> Grant. . . .
>

I think milters are great, but as I explained before we had a very nasty
experience with them in the past and are very concerned with the outcome of
that experience, especially the fact that no one could explain why the
milter or Solaris 8 did what it did. We definitely do not want to go
through that again, as it was very detrimental to the company and disruptive
to our customers. We may try them again when we upgrade our server to
Solaris 9 or 10 on new hardware, but not on 8. :)

Thanks!


From: Grant Taylor on 1 Feb 2007 14:13
Alex Moen wrote:
> Well, the files are all q (lower case), and of course, d (lower case). No
> upper case Q's are in the directory.

....

> No instances of panic or save in the log files (grep -iw panic
> /var/log/maillog ; grep -iw save /var/log/maillog) other than those that are
> contained in domain names or e-mail addresses.

Ok, this makes me think that the files are not from abandoned / orphaned
messages.

> This would be a great help, and actually would probably solve the problem.
> Is there an example somewhere that explains how to do this? And, what is
> the reason that this is not the default behavior?

Put the following in your mc file and rebuild your cf.

define(`confDOUBLE_BOUNCE_ADDRESS', `address(a)domain.tld')

Update `address(a)domain.tld' respectively.

Configure what ever email address you use to then route any messages
that come in to it to /dev/null.

> I think milters are great, but as I explained before we had a very nasty
> experience with them in the past and are very concerned with the outcome of
> that experience, especially the fact that no one could explain why the
> milter or Solaris 8 did what it did. We definitely do not want to go
> through that again, as it was very detrimental to the company and disruptive
> to our customers. We may try them again when we upgrade our server to
> Solaris 9 or 10 on new hardware, but not on 8. :)

*nod* I would consider that a bit over cautious, but caution is not
necessarily a bad thing. If / when you do try milters again on what
ever platform and / or OS you know some symptoms to look for before they
get out of hand.



Grant. . . .

From: Alex Moen on 1 Feb 2007 14:28
"Grant Taylor" <gtaylor(a)riverviewtech.net> wrote in message
news:mailman.138.1170357185.28999.comp.mail.sendmail(a)maillists.riverviewtech.net...
> Alex Moen wrote:
>> Well, the files are all q (lower case), and of course, d (lower case).
>> No upper case Q's are in the directory.
>
> ...
>
>> No instances of panic or save in the log files (grep -iw panic
>> /var/log/maillog ; grep -iw save /var/log/maillog) other than those that
>> are contained in domain names or e-mail addresses.
>
> Ok, this makes me think that the files are not from abandoned / orphaned
> messages.
>
>> This would be a great help, and actually would probably solve the
>> problem. Is there an example somewhere that explains how to do this?
>> And, what is the reason that this is not the default behavior?
>
> Put the following in your mc file and rebuild your cf.
>
> define(`confDOUBLE_BOUNCE_ADDRESS', `address(a)domain.tld')
>
> Update `address(a)domain.tld' respectively.
>
> Configure what ever email address you use to then route any messages that
> come in to it to /dev/null.

OK, I notice in my sendmail.cf file the following line:

#O DoubleBounceAddress=postmaster

So, I removed the # and set an alias for postmaster to /dev/null (actually
that was already there)...

Hopefully this helps! I'll let the group know...

>> I think milters are great, but as I explained before we had a very nasty
>> experience with them in the past and are very concerned with the outcome
>> of that experience, especially the fact that no one could explain why the
>> milter or Solaris 8 did what it did. We definitely do not want to go
>> through that again, as it was very detrimental to the company and
>> disruptive to our customers. We may try them again when we upgrade our
>> server to Solaris 9 or 10 on new hardware, but not on 8. :)
>
> *nod* I would consider that a bit over cautious, but caution is not
> necessarily a bad thing. If / when you do try milters again on what ever
> platform and / or OS you know some symptoms to look for before they get
> out of hand.
>
>
>
> Grant. . . .

Maybe a little overcautious... But when it was a downtime of 2 days because
the filesystem needed to FSCK and recover all the inodes (which were
completely used up), on a server that customers are paying us to use, it was
a big problem. We quickly popped another server up so they could send their
e-mail, but their accounts were all on the machine that was down, so POP and
HTTP were unavailable. Luckily it was a holiday weekend, so most people
were out of town.

Thanks!

Alex


From: Grant Taylor on 1 Feb 2007 14:42
Alex Moen wrote:
> So, I removed the # and set an alias for postmaster to /dev/null (actually
> that was already there)...

Be vary careful doing this as this breaks the address that
administrators will use to contact you if there are problems. I'd
REALLY recommend that you use something other than postmaster and route
it to null. However, it is you own system and you will do what you want
to do. ;)

> Maybe a little overcautious... But when it was a downtime of 2 days because
> the filesystem needed to FSCK and recover all the inodes (which were
> completely used up), on a server that customers are paying us to use, it was
> a big problem. We quickly popped another server up so they could send their
> e-mail, but their accounts were all on the machine that was down, so POP and
> HTTP were unavailable. Luckily it was a holiday weekend, so most people
> were out of town.

*nod*

I was thinking that you would know that you could look in a directory
and see it filling up and stop it before it got to that level, WHEN you
are ready to do the test on what ever version of OS / hardware. ;)



Grant. . . .

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: SYSERR(root): buildaddr: unknown mailer procmail
Next: host name lookup failure