Prev: SYSERR(root): buildaddr: unknown mailer procmail
Next: host name lookup failure
From: Alex Moen on 31 Jan 2007 15:38
Is there a quick easy way to send all email from the local "Mail Delivery
Subsystem" to /dev/null? In effect, I want to disable error messages from
being sent. Our queue seems to be filling up with these, and for some
reason they are not being deleted or dealt with in a timely manner. I would
much rather just bit bucket them than have them sitting aroung sucking up
cycles and processes.

TIA


From: jmaimon on 31 Jan 2007 19:50
On Jan 31, 3:38 pm, "Alex Moen" <a...(a)ndtel.com> wrote:
> Is there a quick easy way to send all email from the local "Mail Delivery
> Subsystem" to /dev/null? In effect, I want to disable error messages from
> being sent. Our queue seems to be filling up with these, and for some
> reason they are not being deleted or dealt with in a timely manner. I would
> much rather just bit bucket them than have them sitting aroung sucking up
> cycles and processes.
>
> TIA


Your queues filling up with bounce messages is a symptom, not the
problem.

The symptom is that you seem to be producing bounces to spam messages.

Eliminating all bounce messages would make your system non-rfc
compliant.

Most likely, it would be fairly sender unfriendly do so as well.

Eliminating only bounces to spam messages is another kettle of fish.

Usualy it is done by not accepting the messages in the first place.

Perhaps this applies to your system?

----------
"How do I let my mx gateway server recognize which recipients are
valid
on the final destionation/next hop server and which are not?"

Which has hit the newsgroup so frequently it really needs to be a faq
entry.

The short answers are:

*

Use ldap routing

see cf/README

+--------------+
| LDAP ROUTING |
-++--------------+

http://www.sendmail.org/m4/ldap_routing.html

*

Use virtusertable with undocumented feature and an entry for each
valid user and a catchall entry that @domain.com error:nouser

_VIRTUSER_STOP_ONE_LEVEL_RECURSION_

*

Use virtusertable with a RHS of "!" for each valid user and a
catchall entry that @domain.com error:nouser

*

Use access db with undocumented feature

define(`_RELAY_FULL_ADDR_', `1')

And put all your users in there

To:u...(a)example.com RELAY

*

use a milter of which there are several.

milter-ahead
j-chkmail
mimedefang
dnsbl
callahead-milter
milter-sav

A list of milters is available at
http://www.jmaimon.com/sendmail/milters

From: Alex Moen on 1 Feb 2007 07:46
OK... Here goes:

<jmaimon(a)ttec.com> wrote in message
news:1170291035.950160.293210(a)s48g2000cws.googlegroups.com...
> On Jan 31, 3:38 pm, "Alex Moen" <a...(a)ndtel.com> wrote:
>> Is there a quick easy way to send all email from the local "Mail Delivery
>> Subsystem" to /dev/null? In effect, I want to disable error messages
>> from
>> being sent. Our queue seems to be filling up with these, and for some
>> reason they are not being deleted or dealt with in a timely manner. I
>> would
>> much rather just bit bucket them than have them sitting aroung sucking up
>> cycles and processes.
>>
>> TIA
>
>
> Your queues filling up with bounce messages is a symptom, not the problem.

Agreed...

> The symptom is that you seem to be producing bounces to spam messages.
> Eliminating all bounce messages would make your system non-rfc
> compliant.

Agreed here too.

> Most likely, it would be fairly sender unfriendly do so as well.
>
> Eliminating only bounces to spam messages is another kettle of fish.
>
> Usualy it is done by not accepting the messages in the first place.
>
> Perhaps this applies to your system?
>
> ----------
> "How do I let my mx gateway server recognize which recipients are
> valid
> on the final destionation/next hop server and which are not?"
>
> Which has hit the newsgroup so frequently it really needs to be a faq
> entry.
>
> The short answers are:
>
> *
>
> Use ldap routing
>
> see cf/README
>
> +--------------+
> | LDAP ROUTING |
> -++--------------+
>
> http://www.sendmail.org/m4/ldap_routing.html
>
> *

Not possible. Not using LDAP as of yet. Soon, but not yet.

> Use virtusertable with undocumented feature and an entry for each
> valid user and a catchall entry that @domain.com error:nouser
>
> _VIRTUSER_STOP_ONE_LEVEL_RECURSION_
>
> *
>
> Use virtusertable with a RHS of "!" for each valid user and a
> catchall entry that @domain.com error:nouser
>
> *

Good idea, but an administrative nightmare with 12000 users.
(undocumented??)

> Use access db with undocumented feature
>
> define(`_RELAY_FULL_ADDR_', `1')
>
> And put all your users in there
>
> To:u...(a)example.com RELAY
>
> *

Again, a good idea, but the nightmare returns. (again, undocumented?)

> use a milter of which there are several.
>
> milter-ahead
> j-chkmail
> mimedefang
> dnsbl
> callahead-milter
> milter-sav
>
> A list of milters is available at
> http://www.jmaimon.com/sendmail/milters

I have tried milters in the past and they created more problems than they
solved. For some reason, we had issues using milter on Solaris 8, where the
software would create 3 files for each incoming message, and only delete 2,
filling up the /var filesystem in a matter of days and destroying our Labor
Day holiday. Milter is no longer, and never will be, an option in this
office, until someone can tell me why this happened, the fault of which was
denied by both the milter community and the OS vendor. We do have spam
filtration in place (through Postini for incoming and Barracuda for
outgoing), but inevitably some spam does make it though, and that is what I
am fighting here.

Symptoms like never deleting undeliverable mail, and mail queues filling up
to a hundred thousand messages in a few days, appears to be a Sendmail
problem, or an improper configuration. Sendmail should delete these
messages after a time limit (which, BTW, is set for 2 days), and not let the
queue grow to such a spectacular size. I have pursued this problem from
many different angles on the newsgroup in the past, and I cannot seem to get
anyone to help solve the problem. I realize that everyone here has other
things better to do and are not compensated, so I am not angry or anything,
don't get me wrong. Just figured I'd asked the question improperly. So,
the drastic measure of stopping all these "friendly" bounces is simply a way
to regain control over this machine and keep the business up and running.
Is it impossible to do this? Even if it is RFC incompliant? We are looking
into the commercial version of Sendmail, but it would be nice to continue
using the open-source version if possible...

Thanks!!!


From: mega on 1 Feb 2007 09:12
Alex Moen wrote:
......

>
> Symptoms like never deleting undeliverable mail, and mail queues filling up
> to a hundred thousand messages in a few days, appears to be a Sendmail
> problem, or an improper configuration. Sendmail should delete these
> messages after a time limit (which, BTW, is set for 2 days), and not let the
> queue grow to such a spectacular size. I have pursued this problem from
> many different angles on the newsgroup in the past, and I cannot seem to get
> anyone to help solve the problem. I realize that everyone here has other
> things better to do and are not compensated, so I am not angry or anything,
> don't get me wrong. Just figured I'd asked the question improperly. So,
> the drastic measure of stopping all these "friendly" bounces is simply a way
> to regain control over this machine and keep the business up and running.
> Is it impossible to do this? Even if it is RFC incompliant? We are looking
> into the commercial version of Sendmail, but it would be nice to continue
> using the open-source version if possible...

You can....

The best answer you got is _use_ldap_routing_

If you cannot deploy a LDAP server in a short timeframe, you may be able
to use the same feature with a local map. Actually building such a map
file is not that difficult. You can then convert to real ldap routing
once your server is up and functional

cheers

Erich
From: Alex Moen on 1 Feb 2007 10:15

"mega" <erich.titl(a)think.ch> wrote in message
news:45c1f554$0$18821$5402220f(a)news.sunrise.ch...
> Alex Moen wrote:
> .....
>
>>
>> Symptoms like never deleting undeliverable mail, and mail queues filling
>> up
>> to a hundred thousand messages in a few days, appears to be a Sendmail
>> problem, or an improper configuration. Sendmail should delete these
>> messages after a time limit (which, BTW, is set for 2 days), and not let
>> the
>> queue grow to such a spectacular size. I have pursued this problem from
>> many different angles on the newsgroup in the past, and I cannot seem to
>> get
>> anyone to help solve the problem. I realize that everyone here has other
>> things better to do and are not compensated, so I am not angry or
>> anything,
>> don't get me wrong. Just figured I'd asked the question improperly. So,
>> the drastic measure of stopping all these "friendly" bounces is simply a
>> way
>> to regain control over this machine and keep the business up and running.
>> Is it impossible to do this? Even if it is RFC incompliant? We are
>> looking
>> into the commercial version of Sendmail, but it would be nice to continue
>> using the open-source version if possible...
>
> You can....
>
> The best answer you got is _use_ldap_routing_
>
> If you cannot deploy a LDAP server in a short timeframe, you may be able
> to use the same feature with a local map. Actually building such a map
> file is not that difficult. You can then convert to real ldap routing
> once your server is up and functional
>
> cheers
>
> Erich

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?

Also, users are being added and deleted daily on this server... Building a
static map file is not an option, as it would not be dynamic as the
passwd/shadow file is.

Thanks


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