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

On Jan 31, 3:38 pm, "Alex Moen" <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...@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

OK... Here goes:

<jmaimon@ttec.com> wrote in message
news:1170291035.950160.293210@s48g2000cws.googlegr oups.com...
> On Jan 31, 3:38 pm, "Alex Moen" <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...@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 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!!!

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 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

"mega" <erich.titl@think.ch> wrote in message
news:45c1f554$0$18821$5402220f@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 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

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 clear the air.



Grant. . . .

"Grant Taylor" <gtaylor@riverviewtech.net> wrote in message
news:mailman.135.1170344835.28999.comp.mail.sendma il@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 , 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 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!

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 , 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@domain.tld')

Update `address@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. . . .

"Grant Taylor" <gtaylor@riverviewtech.net> wrote in message
news:mailman.138.1170357185.28999.comp.mail.sendma il@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 , 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@domain.tld')
>
> Update `address@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 s! 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

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. . . .

OK, here's some more information.... I manually ran the mail queue with the
following command:

# /usr/lib/sendmail -oQ/var/mqueue/worldq -v -q -cf /etc/mail/sendmail.alex

It sat at this line for over an hour:

Running /var/mqueue/worldq/l11M03g9002470 (sequence 2 of 739)
<nicuacalderone@maxxrep.com>... Connecting to mail.maxxrep.com. via esmtp...

Here are my timeouts in the sendmail.alex file:
# timeouts (many of these)
#O Timeout.initial=5m
O Timeout.initial=20s
#O Timeout.connect=5m
O Timeout.connect=20s
#O Timeout.aconnect=0s
O Timeout.aconnect=20s
O Timeout.iconnect=5s
#O Timeout.helo=2m
O Timeout.helo=20s
#O Timeout.mail=5m
O Timeout.mail=20s
#O Timeout.rcpt=1h
O Timeout.datainit=2m
#O Timeout.datablock=1h
#O Timeout.datafinal=1h
#O Timeout.rset=5m
#O Timeout.quit=2m
#O Timeout.misc=2m
O Timeout.misc=20s
#O Timeout.command=1h
O Timeout.ident=0s
#O Timeout.fileopen=60s
#O Timeout.control=2m
O Timeout.queuereturn=2d
O Timeout.queuereturn.normal=2d
O Timeout.queuereturn.urgent=2d
O Timeout.queuereturn.non-urgent=2d
O Timeout.queuereturn.dsn=2d
O Timeout.queuewarn=4h
#O Timeout.queuewarn.normal=4h
#O Timeout.queuewarn.urgent=1h
#O Timeout.queuewarn.non-urgent=12h
#O Timeout.queuewarn.dsn=4h
#O Timeout.hoststatus=30m
#O Timeout.resolver.retrans=5s
#O Timeout.resolver.retrans.first=5s
#O Timeout.resolver.retrans.normal=5s
#O Timeout.resolver.retry=4
#O Timeout.resolver.retry.first=4
#O Timeout.resolver.retry.normal=4
#O Timeout.lhlo=2m
#O Timeout.auth=10m
#O Timeout.starttls=1h

Shouldn't it wait like 20 seconds, determine that the mail server is
unreachable, and move on? It looks to me like the server is stalling on
these queued files and just hangs...

Thanks!

More info to go along with this:

Another queue file that was acting wierd...

Running /var/mqueue/worldq/l11LGHEN020602 (sequence 6 of 775)
<1234567bwyw@email.lu>... Connecting to mail.email.lu. via esmtp...
220 free.email.lu ESMTP Unity v1.0 TestPhase
>>> EHLO ndtc3500.stellarnet.com
250-free.email.lu
250-PIPELINING
250-SIZE 20971520
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250 8BITMIME
>>> MAIL From:<> SIZE=3074 BODY=8BITMIME
250 Ok
>>> RCPT To:<1234567bwyw@email.lu>
>>> DATA
450 <1234567bwyw@email.lu>: Recipient address rejected: User unknown in
local recipient table
<1234567bwyw@email.lu>... Deferred: 450 <1234567bwyw@email.lu>: Recipient
address rejected: User unknown in local recipient table
554 Error: no valid recipients
>>> RSET
250 Ok
<1234567bwyw@email.lu>... Connecting to plop.gms.lu. via esmtp...

Why, after sendmail got the 554 error, did it retry connecting to
plop.gms.lu??? The nslookup shows
[root@ndtc3500 worldq]# nslookup -type=mx gms.lu
Server: ns2.stellarnet.com
Address: 66.163.128.15

Non-authoritative answer:
gms.lu preference = 10, mail exchanger = mail.gms.lu
gms.lu preference = 20, mail exchanger = mail2.gms.lu

Authoritative answers can be found from:
gms.lu nameserver = ns2.gms.lu
gms.lu nameserver = ns.gms.lu
mail.gms.lu internet address = 194.235.201.3
mail2.gms.lu internet address = 194.235.201.1

[root@ndtc3500 worldq]# nslookup plop.gms.lu
Server: ns2.stellarnet.com
Address: 66.163.128.15

Non-authoritative answer:
Name: md.gms.lu
Address: 194.235.201.9
Aliases: plop.gms.lu

Where did it get the idea that it should connect to plop.gms.lu?

Here's the contents of the qfile:
V8
T1170364577
K1170364594
N1
P32382
I79/11/124143
MDeferred: 450 <1234567bwyw@email.lu>: Recipient address rejected: User
unknown in local recipient table
Frs
$_localhost
$r
$slocalhost
${daemon_flags}
${if_addr}66.163.128.10
SMAILER-DAEMON
MDeferred: 450 <1234567bwyw@email.lu>: Recipient address rejected: User
unknown in local recipient table
rRFC822; 1234567bwyw@email.lu
RPF:<1234567bwyw@email.lu>
H?P?Return-Path: <\201g>
H??Received: from localhost (localhost)
by ndtc3500.stellarnet.com with \234 id l11LGHEN020602;
Thu, 1 Feb 2007 15:16:17 -0600 (CST)
H?D?Date: Thu, 1 Feb 2007 15:16:17 -0600 (CST)
H?F?From: Mail Delivery Subsystem <MAILER-DAEMON>
H?x?Full-Name: Mail Delivery Subsystem
H?M?Message-Id: <200702012116.l11LGHEN020602@ndtc3500.stellarnet.c om>
H??To: <1234567bwyw@email.lu>
H??MIME-Version: 1.0
H??Content-Type: multipart/report; report-type=delivery-status;
boundary="l11LGHEN020602.1170364577/ndtc3500.stellarnet.com"
H??Subject: Returned mail: see transcript for details
H??Auto-Submitted: auto-generated (failure)

I don't understand the reason that it is doing this...

TIA!

Alex Moen wrote:
> Running /var/mqueue/worldq/l11LGHEN020602 (sequence 6 of 775)
> <1234567bwyw@email.lu>... Connecting to mail.email.lu. via esmtp...
> 220 free.email.lu ESMTP Unity v1.0 TestPhase
> >>> EHLO ndtc3500.stellarnet.com
> 250-free.email.lu
> 250-PIPELINING
> 250-SIZE 20971520
> 250-VRFY
> 250-ETRN
> 250-STARTTLS
> 250-AUTH LOGIN PLAIN
> 250-AUTH=LOGIN PLAIN
> 250 8BITMIME
> >>> MAIL From:<> SIZE=3074 BODY=8BITMIME
> 250 Ok
> >>> RCPT To:<1234567bwyw@email.lu>
> >>> DATA
> 450 <1234567bwyw@email.lu>: Recipient address rejected: User unknown in
> local recipient table

Um, why is the server Temp Failing for an unknown / invalid recipient? Furthermore why is it doing so after the DATA phase, not after the RCPT phase?

> <1234567bwyw@email.lu>... Deferred: 450 <1234567bwyw@email.lu>: Recipient
> address rejected: User unknown in local recipient table
> 554 Error: no valid recipients
> >>> RSET
> 250 Ok
> <1234567bwyw@email.lu>... Connecting to plop.gms.lu. via esmtp...

This is as I would expect.

> Why, after sendmail got the 554 error, did it retry connecting to
> plop.gms.lu??? The nslookup shows
> [root@ndtc3500 worldq]# nslookup -type=mx gms.lu

Wrong domain to do an MX query for.

> Where did it get the idea that it should connect to plop.gms.lu?

nslookup -query=mx email.lu
Server: 206.152.114.66
Address: 206.152.114.66#53

Non-authoritative answer:
email.lu mail exchanger = 10 mail.email.lu.
email.lu mail exchanger = 20 plop.gms.lu.

plop.gms.lu is a backup mail exchanger (MX) for the email.lu domain. Thus, I would expect Sendmail to connect to plop.gms.lu.

> I don't understand the reason that it is doing this...

MX records are telling it to do so.

With the fact that email.lu and plop.gms.lu are returning Temp Fails on unknown recipients, Sendmail will keep retrying to send messages until they expire, I think. This in and of its self may be why messages never left the mail queue.

Can / Will someone with more experience in such a situation please clarify this?

Per Hedeland: Do you have any thing to add to this / correct me?



Grant. . . .

"Grant Taylor" <gtaylor@riverviewtech.net> wrote in message
news:mailman.142.1170370768.28999.comp.mail.sendma il@maillists.riverviewtech.net...
> Alex Moen wrote:
>> Running /var/mqueue/worldq/l11LGHEN020602 (sequence 6 of 775)
>> <1234567bwyw@email.lu>... Connecting to mail.email.lu. via esmtp...
>> 220 free.email.lu ESMTP Unity v1.0 TestPhase
>> >>> EHLO ndtc3500.stellarnet.com
>> 250-free.email.lu
>> 250-PIPELINING
>> 250-SIZE 20971520
>> 250-VRFY
>> 250-ETRN
>> 250-STARTTLS
>> 250-AUTH LOGIN PLAIN
>> 250-AUTH=LOGIN PLAIN
>> 250 8BITMIME
>> >>> MAIL From:<> SIZE=3074 BODY=8BITMIME
>> 250 Ok
>> >>> RCPT To:<1234567bwyw@email.lu>
>> >>> DATA
>> 450 <1234567bwyw@email.lu>: Recipient address rejected: User unknown in
>> local recipient table
>
> Um, why is the server Temp Failing for an unknown / invalid recipient?
> Furthermore why is it doing so after the DATA phase, not after the RCPT
> phase?
>
>> <1234567bwyw@email.lu>... Deferred: 450 <1234567bwyw@email.lu>: Recipient
>> address rejected: User unknown in local recipient table
>> 554 Error: no valid recipients
>> >>> RSET
>> 250 Ok
>> <1234567bwyw@email.lu>... Connecting to plop.gms.lu. via esmtp...
>
> This is as I would expect.
>
>> Why, after sendmail got the 554 error, did it retry connecting to
>> plop.gms.lu??? The nslookup shows
>> [root@ndtc3500 worldq]# nslookup -type=mx gms.lu
>
> Wrong domain to do an MX query for.
>
>> Where did it get the idea that it should connect to plop.gms.lu?
>
> nslookup -query=mx email.lu
> Server: 206.152.114.66
> Address: 206.152.114.66#53
>
> Non-authoritative answer:
> email.lu mail exchanger = 10 mail.email.lu.
> email.lu mail exchanger = 20 plop.gms.lu.
>
> plop.gms.lu is a backup mail exchanger (MX) for the email.lu domain.
> Thus, I would expect Sendmail to connect to plop.gms.lu.
>
>> I don't understand the reason that it is doing this...
>
> MX records are telling it to do so.

Yep. I get it. I missed that. Duh!!!

> With the fact that email.lu and plop.gms.lu are returning Temp Fails on
> unknown recipients, Sendmail will keep retrying to send messages until
> they expire, I think. This in and of its self may be why messages never
> left the mail queue.
>
> Can / Will someone with more experience in such a situation please
> clarify this?
>
> Per Hedeland: Do you have any thing to add to this / correct me?
>
>
>
> Grant. . . .



So, if Sendmail will keep trying until they expire, that would be reflected
in the setting I have for one of the queuereturns, which I have set for 2
days, right? So, can I change the behavior to dump immediately in the case
of unknown recipients, and have it drop them immediately on the unknown?
Or, does it do that already and I am just not waiting long enough?

Thanks for the so far, Grant... And for pointing out my "duhness"!

On Feb 1, 10:15 am, "Alex Moen" <a...@ndtel.com> wrote:
> "mega" <erich.t...@think.ch> wrote in message
>
> news:45c1f554$0$18821$5402220f@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 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?

Timeouts and runners per queue.

On Feb 1, 7:46 am, "Alex Moen" <a...@ndtel.com> wrote:
> OK... Here goes:
>
> <jmai...@ttec.com> wrote in message
>
> news:1170291035.950160.293210@s48g2000cws.googlegr oups.com...
>
>

>
>
> 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,

callahead-milter does not create any files per mail. Odds are neither
do the others.

Sendmail? Perhaps you should look at your SuperSafe option.

What version of sendmail, what milters and versions were you trying?

Perhaps you should try using a seperate milter host running on modern
hardware and modern software. I expect you would have equally good
results with Debian GNU/Linux 4.0 or any current BSD.

> 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

Sounds like cutting off your nose to spite your face. Milter is the
only real way to access the full potential of sendmail in a modern
mail system.

In article <12s4sq1qvgnti59@corp.supernews.com> "Alex Moen"
<alexm@ndtel.com> writes:
>
>"Grant Taylor" <gtaylor@riverviewtech.net> wrote in message
>news:mailman.142.1170370768.28999.comp.mail.sendm ail@maillists.riverviewtech.net...
>> Alex Moen wrote:
>>> Running /var/mqueue/worldq/l11LGHEN020602 (sequence 6 of 775)
>>> <1234567bwyw@email.lu>... Connecting to mail.email.lu. via esmtp...
>>> 220 free.email.lu ESMTP Unity v1.0 TestPhase
>>> >>> EHLO ndtc3500.stellarnet.com
>>> 250-free.email.lu
>>> 250-PIPELINING
>>> 250-SIZE 20971520
>>> 250-VRFY
>>> 250-ETRN
>>> 250-STARTTLS
>>> 250-AUTH LOGIN PLAIN
>>> 250-AUTH=LOGIN PLAIN
>>> 250 8BITMIME
>>> >>> MAIL From:<> SIZE=3074 BODY=8BITMIME
>>> 250 Ok
>>> >>> RCPT To:<1234567bwyw@email.lu>
>>> >>> DATA
>>> 450 <1234567bwyw@email.lu>: Recipient address rejected: User unknown in
>>> local recipient table
>>
>> Um, why is the server Temp Failing for an unknown / invalid recipient?

Good question - I think I saw in another thread reasoning to the effect
that "our mail system is always broken, so we always tempfail since it
gives us the opportunity to apply a band-aid for each incorrectly
non-accepted message, and accept it at a later try without the sender
noticing the brokenness (much)". Well, maybe those weren't the exact
words...

>> Furthermore why is it doing so after the DATA phase, not after the RCPT
>> phase?

It's not after the DATA phase (then there would would have been a
line-with-a-dot-alone in the transcript), but after the DATA *command*.
This is due to PIPELINING.

>>> <1234567bwyw@email.lu>... Deferred: 450 <1234567bwyw@email.lu>: Recipient
>>> address rejected: User unknown in local recipient table
>>> 554 Error: no valid recipients
>>> >>> RSET
>>> 250 Ok
>>> <1234567bwyw@email.lu>... Connecting to plop.gms.lu. via esmtp...
>>
>> This is as I would expect.
>>
>>> Why, after sendmail got the 554 error, did it retry connecting

The 554 is an inevitable result of PIPELINING when all recipients were
temp- *or* perm-rejected - it's not relevant to the fate of the message,
only the per-recipient rejections are.

>> With the fact that email.lu and plop.gms.lu are returning Temp Fails on
>> unknown recipients, Sendmail will keep retrying to send messages until
>> they expire, I think. This in and of its self may be why messages never
>> left the mail queue.

Well, as you say, they should only be retried "until they expire" (2
days in this setup I believe), so it doesn't explain "never".

>> Per Hedeland: Do you have any thing to add to this / correct me?

Huh? Why me?:-)

>So, if Sendmail will keep trying until they expire, that would be reflected
>in the setting I have for one of the queuereturns, which I have set for 2
>days, right?

It should, provided that your sendmail is doing its periodic queue runs
(normally initiated by the MTA daemon based on the -q<time> commandline
argument). But if your queue runs get stuck on many messages like the
one you mentioned earlier, they may not be all that effective. You
should try to investigate why that happens, i.e. what sendmail is
actually waiting for in those cases - e.g. no normal OS TCP/IP stack is
prepared to wait for an hour for the TCP connection to succeed, but
(e.g.) having lots of non-responding name servers (or lots of responding
name server that try to talk to the same non-responding one) configred
could make a DNS lookup attempt take almost forever. Packet sniffing
using e.g. tcpdump may be a useful first step, or running sendmail with
more debugging on - -d8.8 will show DNS lookups, -d1-99.9 will show
everything but still not at the max level of detail.

> So, can I change the behavior to dump immediately in the case
>of unknown recipients, and have it drop them immediately on the unknown?

A MTA is not allowed to base its actions on the *text* of the responses,
only the return code. All 4xx codes mean "didn't work now, try later",
450 specifically means

450 Requested mail action not taken: mailbox unavailable
(e.g., mailbox busy)

which is assumed to be a transient condition, as opposed to

550 Requested action not taken: mailbox unavailable
(e.g., mailbox not found, no access, or command rejected
for policy reasons)

- it would be broken to bounce a message on the first receipt of 450
("drop" or "dump" would be even more broken). But of course the source
is available for modification...

--Per Hedeland
per@hedeland.org

On 02/02/07 19:02, Per Hedeland wrote:
> Good question - I think I saw in another thread reasoning to the effect
> that "our mail system is always broken, so we always tempfail since it
> gives us the opportunity to apply a band-aid for each incorrectly
> non-accepted message, and accept it at a later try without the sender
> noticing the brokenness (much)". Well, maybe those weren't the exact
> words...

Oh, wow! I have not had enough alcohol for that answer.

> It's not after the DATA phase (then there would would have been a
> line-with-a-dot-alone in the transcript), but after the DATA *command*.
> This is due to PIPELINING.

*nod* I never use PIPELINING when I'm testing things manually, so I
would not know.

> The 554 is an inevitable result of PIPELINING when all recipients were
> temp- *or* perm-rejected - it's not relevant to the fate of the message,
> only the per-recipient rejections are.

*nod*

> Well, as you say, they should only be retried "until they expire" (2
> days in this setup I believe), so it doesn't explain "never".

That is what I thought.

> Huh? Why me?:-)

B/c I like picking on someone that has convinced me that they know more
about a subject than I believe I know about it. IMHO, you are "Guilty
as charged.".

> - it would be broken to bounce a message on the first receipt of 450
> ("drop" or "dump" would be even more broken). But of course the source
> is available for modification...

We all know and some of us have to work with MTAs, or at least things
that claim to be MTAs, that are even more broken than that.



Grant. . . .

"Per Hedeland" <per@hedeland.org> wrote in message
news:eq0mvd$2l6d$3@hedeland.org...
> In article <12s4sq1qvgnti59@corp.supernews.com> "Alex Moen"
> <alexm@ndtel.com> writes:
>>
>>"Grant Taylor" <gtaylor@riverviewtech.net> wrote in message
>>news:mailman.142.1170370768.28999.comp.mail.send mail@maillists.riverviewtech.net...
>>> Alex Moen wrote:
>>>> Running /var/mqueue/worldq/l11LGHEN020602 (sequence 6 of 775)
>>>> <1234567bwyw@email.lu>... Connecting to mail.email.lu. via esmtp...
>>>> 220 free.email.lu ESMTP Unity v1.0 TestPhase
>>>> >>> EHLO ndtc3500.stellarnet.com
>>>> 250-free.email.lu
>>>> 250-PIPELINING
>>>> 250-SIZE 20971520
>>>> 250-VRFY
>>>> 250-ETRN
>>>> 250-STARTTLS
>>>> 250-AUTH LOGIN PLAIN
>>>> 250-AUTH=LOGIN PLAIN
>>>> 250 8BITMIME
>>>> >>> MAIL From:<> SIZE=3074 BODY=8BITMIME
>>>> 250 Ok
>>>> >>> RCPT To:<1234567bwyw@email.lu>
>>>> >>> DATA
>>>> 450 <1234567bwyw@email.lu>: Recipient address rejected: User unknown in
>>>> local recipient table
>>>
>>> Um, why is the server Temp Failing for an unknown / invalid recipient?
>
> Good question - I think I saw in another thread reasoning to the effect
> that "our mail system is always broken, so we always tempfail since it
> gives us the opportunity to apply a band-aid for each incorrectly
> non-accepted message, and accept it at a later try without the sender
> noticing the brokenness (much)". Well, maybe those weren't the exact
> words...

Very eloquent!

>>> Furthermore why is it doing so after the DATA phase, not after the RCPT
>>> phase?
>
> It's not after the DATA phase (then there would would have been a
> line-with-a-dot-alone in the transcript), but after the DATA *command*.
> This is due to PIPELINING.
>
>>>> <1234567bwyw@email.lu>... Deferred: 450 <1234567bwyw@email.lu>:
>>>> Recipient
>>>> address rejected: User unknown in local recipient table
>>>> 554 Error: no valid recipients
>>>> >>> RSET
>>>> 250 Ok
>>>> <1234567bwyw@email.lu>... Connecting to plop.gms.lu. via esmtp...
>>>
>>> This is as I would expect.
>>>
>>>> Why, after sendmail got the 554 error, did it retry connecting
>
> The 554 is an inevitable result of PIPELINING when all recipients were
> temp- *or* perm-rejected - it's not relevant to the fate of the message,
> only the per-recipient rejections are.
>
>>> With the fact that email.lu and plop.gms.lu are returning Temp Fails on
>>> unknown recipients, Sendmail will keep retrying to send messages until
>>> they expire, I think. This in and of its self may be why messages never
>>> left the mail queue.
>
> Well, as you say, they should only be retried "until they expire" (2
> days in this setup I believe), so it doesn't explain "never".

I think the "never" comes in due to the number of queued messages, and the
fact that the queue run doesn't make it to the old messages before
breaking... See my addition below.

>>> Per Hedeland: Do you have any thing to add to this / correct me?
>
> Huh? Why me?:-)

Who better???

>>So, if Sendmail will keep trying until they expire, that would be
>>reflected
>>in the setting I have for one of the queuereturns, which I have set for 2
>>days, right?
>
> It should, provided that your sendmail is doing its periodic queue runs
> (normally initiated by the MTA daemon based on the -q<time> commandline
> argument). But if your queue runs get stuck on many messages like the
> one you mentioned earlier, they may not be all that effective. You
> should try to investigate why that happens, i.e. what sendmail is
> actually waiting for in those cases - e.g. no normal OS TCP/IP stack is
> prepared to wait for an hour for the TCP connection to succeed, but
> (e.g.) having lots of non-responding name servers (or lots of responding
> name server that try to talk to the same non-responding one) configred
> could make a DNS lookup attempt take almost forever. Packet sniffing
> using e.g. tcpdump may be a useful first step, or running sendmail with
> more debugging on - -d8.8 will show DNS lookups, -d1-99.9 will show
> everything but still not at the max level of detail.

OK, some new information about this case... The previous paragraph got me
thinking about what was happening on quite a few of the queue files. So, I
manually ran the queue, found one that was hanging up, and started checking
things out. I did this on 3 different instances, and found that the lookup
for an MX record is returning a very strange answer. For instance:

Running /var/mqueue/worldq/l13FbuHW026989 (sequence 5 of 3751)
<boothltc.com@tabii.net>... Connecting to tabii.net. via esmtp...

[root@ndtc3500 worldq]# nslookup -type=mx tabii.net
Server: ns2.stellarnet.com
Address: 66.163.128.15

Authoritative answers can be found from:
tabii.net
origin = dns1.name-services.com
mail addr = info.name-services.com
serial = 2002050701
refresh = 10001 (2h46m41s)
retry = 1801 (30m1s)
expire = 604801 (1w1s)
minimum ttl = 181 (3m1s)

I have never seen this type of answer before. Where is the
non-authoritative answer? Like you said, Per, a non-responding name server?
If so, what is the fix? Is there a timeout for this type of situation,
where if the DNS query is not returned within, say, 1 minute, to declare
that the message is undeliverable and dump it?


In another case, the lookup was successful, but the process still sat there.
A telnet to port 25 of the looked-up mailserver produced:
[root@ndtc3500 mail]# telnet mail.drawaid.com 25
Trying 65.106.66.254...
telnet: Unable to connect to remote host: Connection timed out

Is there a timeout value for this instance as well? It seemed to take an
awfully long time for the smtp process to timeout (I