SENDMAIL Bounce Problems


The dominant software used for mail delivery is SENDMAIL (it is also the software that RootsWeb uses) and the errors/comments that we see mostly originate from that software, thus the plethora of 'Returned mail:' messages with explanations.

There is other mail delivery software that is becoming more widely used,eg. QMAIL, and the error messages explanations for that are still in their infancy. There is also a number of ISPs who have developed their own error messages and as these come attention we will add these too (you can help with this by bringing them to our notice).



Subject: Returned mail: blah blah blah  of bounced message

FATAL problems existing ...

FATAL problems existing ... (digests)

TRANSIENT problems existing ...




FATAL Problems existing ...  
From:      Mail Delivery Subsystem <MAILER-DAEMON@rootsweb.com>

To: <GENANZ-L-request@rootsweb.com>
Subject: Returned mail: Service unavailable
The original message was received at Tue, 24 Mar 1998 14:26:50 -0800 (PST)from slist@localhost
----- The following addresses had permanent fatal errors -----
jones@sale.schnet.edu.au
----- Transcript of session follows -----
dogma@nlc.net.au... Deferred: Operation timed out with mail.nlc.net.au.
51 jones@sale.schnet.edu.au... timeout waiting for input during client EHLO
451 jones@sale.schnet.edu.au... reply: read error from gateway.sale.schnet.edu.au
.... while talking to mail01.sal.aone.net.au.:>>> RCPT To:<jones@sale.schnet.edu.au><<<
571 <jones@sale.schnet.edu.au>... relay denied for <schnet.edu.au>.
554 jones@sale.schnet.edu.au... Service unavailable
This is quite often seen when an ISP or one of the ISPs along the mail trail is not relaying (passing along) messages.This could be because one of the servers is 'sick' or it could be that is using an old trail and one of the servers along the trail doesn't pass on mail anymore.  There can be lots of reasons.  It maybe either a temporary or a permanent problem and there is nothing that you can do directly.

Do you remove them manually?  That is up to you, but check the full headers (X-Diagnostic: lines)  to make sure that their email address is being identified and counted.

Tim the Guru adds: -- This often seems to happen when a system is either upgrading or reconfiguring its mail system: during the configuration, the system becomes confused for a few minutes and thinks that every mail is an attempted relay.  Indeed, it's so common that my stock advice now is just to ignore this message, if it only happens once.  If it happens twice or more over a period of a day or so, that's cause for concern.

It may not even be possible to write to anyone at the anti-relay domain, which makes it difficult for list admins to do anything. If the problem is that bad, the odds are that someone there will eventually notice and fix their mail server, but in the meantime, list admins can feel free to forward such `don't relay' messages to listmaster@rootsweb.com,and we'll try to get in touch with the problem site.

From:      Mail Delivery Subsystem <MAILER-DAEMON@localhost.localdomain>

To: <GENBRIT-L-request@rootsweb.com>
Subject: Returned mail: Service unavailable
The original message was received at Sat, 28 Feb 1998 19:34:30 GMT from punt-1a.mail.demon.net [194.217.242.134]
----- The following addresses had permanent fatal errors -----
<blah-blah@tower-house.demon.co.uk>
----- Transcript of session follows -----
... while talking to punt-1.mail.demon.net.: >> DATA <<
554 [ No such file or directory ] Message has traveled too many hops  
554 <blah-blah@tower-house.demon.co.uk>... Service unavailable
Comes under the same subject heading and with the same result but here one sees buried in the body text the messagetraveled too many hops (or sometimesexceeded xx hops) which again refers to an internal configuration within the receiving ISP.  It may or may not be a temporary problem, depending on the awareness/responsiveness of the offending ISP.

Do you remove them manually?  If SmartList is not going to do it, YES, as this problem is not necessarily going to resolve itself.


From:      Mail Delivery Subsystem <MAILER-DAEMON@fujitsu.com>

Subject: Returned mail: Too many hops 28 (25 max):
from <GENANZ-L-request@rootsweb.com> via tatsy26.tnt.com, to <dynamite@tnt.com>
To: <GENANZ-L-request@rootsweb.com> 
To: postmaster@fujitsuI.fujitsu.com
The original message was received at Thu, 26 Mar 1998 15:26:48 -0800 (PST)from tatsy26.tnt.com.au [203.26.190.16]
----- The following addresses had permanent fatal errors -----
<dynamite@tnt.com>
----- Transcript of session follows -----
554 Too many hops 28 (25 max):
from <GENANZ-L-request@rootsweb.com> via tatsy26.tnt.com, to <dynamite@tnt.com>
Basically as previously stated, there is an internal configuration problem at the receiving ISP.  It may be temporary,it may not.

Do you remove them manually?  If Smartlist is not going to do it, YES, as this problem is not necessarily going to resolve itself.


From:       Mail Delivery Subsystem <MAILER-DAEMON@rootsweb.com>

To: <GENANZ-D-request@rootsweb.com>
Subject: Returned mail: Cannot send message within 5 days
The original message was received at Thu, 26 Feb 1998 04:31:05 -0800 (PST)from slist@localhost
----- The following addresses had permanent fatal errors -----
beach@coffs.net.au
----- Transcript of session follows -----
beach@coffs.net.au
... Deferred: Operation timed out with www.coffs.net.au.
Message could not be delivered for 5 days Message will be deleted from queue
This one error will be one of the biggest bug bears that you will face as a list admin, especially if you run a busy list. What has happened in this case is that a server has not been able to deliver mail message for five days (note five is the general default but it could be any number).  The big problem is that there will generally be five days worth of posts behind this one that won't have been delivered before the bounces come back and the subscriber is auto-unsubscribed.  You will now face five days of bounced mail from such an account and there is NOTHING that you can do but grit you teeth and bear with it.  [Those with busy lists may want to learn how to filter their mail.]

Do you remove them manually?  If Smartlist is not going to, YES.  Mind you be well aware that quite often SmartList has well and truly removed them before you get to them. Be vigilant that you do not unsubscribe another address by accident.
Here is a part of an email showing advice.


X-Diagnostic: Mail to fp-1.rootsweb.com bounced 15 times  

X-Diagnostic: Bounces exceed threshold of 4
X-Diagnostic: Not confident enough to autoremove the offending address  
57 archiver@lists.rootsweb.com   17410 fp-1.rootsweb.com
What's happening is that after Lone_Ranger@sprynet.com got removed, SmartList sort of forgets that they were ever there, and so gets really confused about any subsequent bounces for their address.  The list server continues to process bounces for Lone_Ranger@sprynet.com, and tries desperately to figure out which address on your list is bouncing.  Of course, no address *on* the list is bouncing -- it's an address that was already removed that's still bouncing.

This diagnostic message just means
"The closest match on your list to the address that's bouncing is archiver@lists.rootsweb.com. But, you know, that *really* doesn't look right, so I'm not going to do anything about it."

So you don't need to worry about this right now.  You would need to do something if the bouncer's address hadn't correctly been unsubscribed,or if SmartList accidentally unsubscribed the wrong person.  Neither of these is the case here, so you just need to ride out the two days' worth of bounces.


From:      Mail Delivery Subsystem <MAILER-DAEMON@spice.idl.com.au>

To: <GENANZ-L-request@rootsweb.com>
Subject: Returned mail: Can't create output: Error 0
The original message was received at Sun, 15 Mar 1998 10:51:39 +1100from bl-30.rootsweb.com [207.113.245.30]
----- The following addresses had permanent fatal errors -----
<jack@idl.net.au><jill@idl.net.au>
----- Transcript of session follows -----
procmail: No space left to finish writing "/var/spool/mail/jack"550 <jack@idl.net.au>
... Can't create output: Error 0 procmail: No space left to finish writing "/var/spool/mail/jill"
550 <jill@idl.net.au>... Can't create output: Error 0
The problem here is that the ISP (idl.net.au)at the receiving end (idl.net.au) has problems with their setup and they cannot write the mail to the subscriber(s)  mail directory,so they are therefore bouncing it back to you.  It is more than likely a temporary problem.

Do you remove them manually?  If Smartlist is not going to do it and it is a continuing problem, YES, as this problem is not necessarily going to resolve itself.


From:      Mail Delivery Subsystem <MAILER-DAEMON@vector.wantree.com.au>

Subject: Returned mail: Cannot reopen DB database /etc/mail/virtdom
To: <GENANZ-L-request@rootsweb.com>
The original message was received at Wed, 11 Mar 1998 15:38:36 +0800 from bl-30.rootsweb.com [207.113.245.30]
----- The following addresses had permanent fatal errors -----
<humpty_dumpty@wantree.com.au>
----- Transcript of session follows -----
451 cannot flock(/etc/mail/virtdom.db, fd=11, type=1, omode=37777777777, euid=0): Device or resource busy
451 cannot flock(/etc/mail/virtdom.db, fd=6, type=1, omode=37777777777, euid=0): Device or resource busy
554 db_map_open: cannot lock /etc/mail/virtdom.db
451 Cannot open hash database /etc/mail/virtdom: Invalid argument
554 Cannot reopen DB database /etc/mail/virtdom
The problem here is that the ISP at the receiving end (wantree.com.au) has problems with their setup and they cannot write the mail to the subscriber(s)  mail directory, so they are therefore bouncing it back to you.  It is more than likely a temporary problem.
Do you remove them manually?  If Smartlist is not going to do it and it is a continuing problem, YES, as this problem is not necessarily going to resolve itself.


From:      Mail Delivery Subsystem <MAILER-DAEMON@uow.edu.au>

To: <IIGS-NEWSLETTER-L-request@rootsweb.com>
Subject: Returned mail: Insufficient permission: Error 0
The original message was received at Wed, 4 Mar 1998 22:55:47 +1100 (EST) 
from fp-1.rootsweb.com [207.113.233.233]
----- The following addresses had permanent fatal errors -----
bbbsheep (expanded from: <Baa_baa_black_sheep@uow.edu.au>)
----- Transcript of session follows -----
550 bbbsheep... Insufficient permission: Error 0
The problem here is that the ISP at the receiving end (uow.edu.au) has problems with their setup (eg. Unix permissions on their POP server) and they cannot write the mail to the subscriber(s)  mail directory, so they are therefore bouncing it back to you.  It is more than likely a temporary problem.

Do you remove them manually? If Smartlist is not going to do it and it is a continuing problem, YES, as this problem is not necessarily going to resolve itself.



From:      Mail Delivery Subsystem <MAILER-DAEMON@rootsweb.com>

To: <GENANZ-L-request@rootsweb.com>
Subject: Returned mail: User unknown
The original message was received at Tue, 3 Mar 1998 13:18:26 -0800 (PST)from slist@localhost
----- The following addresses had permanent fatal errors -----
jetson_fam@trump.net.au
----- Transcript of session follows -----b_rubble@outeast.cyberspace.net.au,f_flintstone@outeast.cyberspace.net.au
...Deferred: Operation timed out with mail-east.cyberspace.net.au
.... while talking to diamond.trumpet.com.:>>> RCPT To:<jetson_fam@trump.net.au><<<
550 <jetson_fam@trump.net.au>... Sorry 7550 jetson_fam@trump.net.au... User unknown
Here it seems that the subscriber jetson_fam@trump.net.au has set the receipt confirmation ON for a mail through the list. Their mail was distributed and at the server at cyberspace.net.auit bounced it back to trump.net.au which has then bounced it back to the list admin. Two servers both having problems, but in this case the original author does exist.  Temporary problem, ignore it.

Important: These specific messages are worth investigating that one step further. If someone has subscribed to the list and they have entered their email address incorrectly (especially as SmartList will use the email address in the Reply-To field), then the subscription email address will be wrong. If one looks further into the message and sees that what has bounced is the confirmation of the subscription notification,then you might be able to pick out the proper email address.  Remember that newbies are renowned for putting their postal address in the Reply-To field rather than their email address.

Do you remove them manually?  Probably not worth it as long as it is not a perennial problem, otherwise it should just go away.

From:      Mail Delivery Subsystem <MAILER-DAEMON@tiernet.net>

To: <list admins-l@rootsweb.com>
Subject: Returned mail: User unknown
   
----- The following addresses had permanent fatal errors -----

<about@tiernet.net>
   
----- Transcript of session follows -----

550 <about@tiernet.net>... User unknown
An ISP's claim 'If our mail server cannot do a reverse DNS lookup on the machine that is attempting to send us mail, our machines will reject it. ...'

Tim the Guru says in response: -
This doesn't sound like a reverse DNS failure. It sounds more like a big-time screw-up on the part of Bob's ISP. When bounces are provoked by reverse DNS failures,the listmaster will typically get a notice that says something like this:

    ----- The following addresses had permanent fatal errors -----

<fooble@grobble.org>

----- Transcript of session follows -----
451 grobble.org... Domain does not resolve

I don't remember what the numeric error code is,and the exact message will differ from one ISP to another, but you get the picture -- the bounce notification will say something about `DNS failures'or a `domain not resolving'.

The bounces from tier net.net didn't say this. They said user unknown.  In my experience, this means one of two things:
 * User really unknown.  ie. they've closed their account and moved on, or they never existed to begin with.
 * ISP screwup.  Poorly-planned mail system upgrades will cause this.

Moreover, if tiernet.net were refusing mail from RootsWeb due to reverse DNS failures, the bounces that Ron got would have been from MAILER-DAEMON@rootsweb.com.  Bob's bounces are from MAILER-DAEMON@tiernet.net,which means that his system actually accepted the mail from RootsWeb but then decided not to deliver it to him.

Summary: I don't think tiernet has accurately diagnosed the problem, and Bob should write to his technical support folks and ask why the mail system has been returning mail with phony "user unknown"messages.


From:      Mail Delivery Subsystem <MAILER-DAEMON@villagenet.com>

To: <GENANZ-L-request@rootsweb.com>
Subject: Returned mail: Bad usage
The original message was received at Mon, 2 Mar 1998 18:37:29 -0500 (EST)from bl-30.rootsweb.com [207.113.245.30]
----- The following addresses had permanent fatal errors -----
<bugsy@villagenet.com>
----- Transcript of session follows -----
Usage: mail [-r] [-t] [-p] [-q] [-e] [-h seqno] [-f fname] [people] .. .
500 <bugsy@villagenet.com>...Bad usage
Well, who knows exactly what is going on here? As the rest of all RootsWeb gets delivered really well, so I have decided that we will say that there is something wrong with the receiving ISP's setup.  Hey the blame has to be shifted wherever possible. <vbg>

Do you remove them manually?  If Smartlist is not going to do it and it is a continuing problem, YES.

Tim the Guru adds: - It's a problem with the remote system's mail configuration.  Their mailer-daemon needs to invoke a particular program in order to finish delivering mail to a user.  That program is usually called `mail', unsurprisingly enough.  This message means that the system administrators were careless when they set up the server, and didn't invoke the `mail' program the right way, so it couldn't deliver mail to the user.

Like the `can't relay' problem, it may be possible to write to the site's postmaster, but maybe not.  If not, list admins can forward the bounce notice to listmaster@rootsweb.com.


From:      Mail Delivery Subsystem <MAILER-DAEMON>

Subject: Returned mail: Host unknown (Name server: rh20.com: host not found)
The original message was received at Tue, 24 Mar 1998 07:02:22 -0600 (CST)from dodg-cas1-cs-47.dial.mhtc.net [156.46.16.65]
----- The following addresses had permanent fatal errors -----
<bj@rh20.com>
----- Transcript of session follows -----
550 <bj@rh20.com>... Host unknown (Name server: rh20.com: host not found)
The host/ISP/server does not exist.  Now this can mean that the server is down, failed a DNS lookup or does not actually exist at all (maybe someone just cannot type).  If this is a bounce from a subscription notice, bury into the bowels of the message as explained above and see if you can decipher the real subscription address.Up to you whether you do DNS or MX searches, and if you don't know what these are don't worry about it.

Do you remove them manually? Generally YES.  If it does not exist then there is no point in letting it bounce out.  If you are unsure you can let it bounce and be removed. If SmartList is having problems, definitely give it a helping hand.


From:      Mail Delivery Subsystem <MAILER-DAEMON@rootsweb.com>

To: <GEN-OBIT-request@rootsweb.com>
Subject: Returned mail: @gte.net... user address required
The original message was received at Wed, 25 Mar 1998 21:46:39 -0800 (PST)from slist@localhost
----- The following addresses had permanent fatal errors -----
@gte.net
----- Transcript of session follows -----
553 @gte.net... user address required
In this situation what has generally happened is that someone has subscribed to your list and they have not complete their Reply-To: field properly (as previously stated SmartList preferably uses the Reply-To: field for subscriptions).

Do you remove them manually? YES. No mail is ever going to get to them, but beware that SmartList may already have unsubscribed them if there has been sufficient traffic.  If you have a look at the first bounced message in this case, it is generally a bounced subscription confirmation and usually you can see their real email address and if you wish you can subscribe that name.  Below is the rest of the bounced mail from above.

From:      Mail Delivery Subsystem <MAILER-DAEMON@mail1.auracom.net>

To: postmaster@mail1.auracom.net
Subject: Returned mail: Local configuration error
The original message was received at Sun, 1 Mar 1998 22:35:43 -0500 (EST)from pearl.mhtc.net [208.135.157.10]
----- The following addresses had permanent fatal errors -----
<big_bad_wolf@tra.auracom.com>
----- Transcript of session follows -----
554 MX list for tra.auracom.com. points back to mail1.auracom.net
554 <big_bad_wolf@tra.auracom.com>... Local configuration error
This is a problem at the subscriber's ISP. Nothing you can do about it.  It may be temporary, it may not.

Do you remove them manually?  If Smartlist is not going to do it, YES, as this problem is not necessarily going to resolve itself.

Tim the Gurus says: - Very unlikely to be a temporary problem.  The administrators need to be notified that their MX records are improperly set up.  This is probably beyond the reach of most list admins, so tell listmaster@rootsweb.comand include the error message when doing so.


From:      Mail Delivery Subsystem <MAILER-DAEMON@raex.com>

To: <RIGENWEB-L-request@rootsweb.com>
Subject: Returned mail: mx2.raex.com. config error: mail loops
back to me (MX problem?)

----- The following addresses had permanent fatal errors -----
<charlemagne@raex.com>
----- Transcript of session follows -----
553 mx2.raex.com. config error: mail loops back to me (MX problem?) <charlemagne@raex.com>
...Deferred: Connection refused by mx6.raex.com.
This is a problem at the subscriber's ISP. Nothing you can do about it.  It may be temporary, it may not.

Do you remove them manually?  If Smartlist is not going to do it, YES, as this problem is not necessarily going to resolve itself.

Tim the Gurus says:- Ditto for the above. MX problems are probably not transitory, and it probably makes sense to advise listmaster@rootsweb.comof the problem.


From:      Mail Delivery Subsystem <MAILER-DAEMON@rootsweb.com>

To: <RIGENWEB-L-request@rootsweb.com>
Subject: Returned mail: Data format error
----- The following addresses had permanent fatal errors -----
lululand@bright.net
----- Transcript of session follows -----
451 rtees@usa.net... reply: read error from mxpool01.netaddress.usa.net.
rtees@usa.net... Deferred:Connection reset by mxpool01.netaddress.usa.netbigwalker@mail2.nai.net
... Deferred: Connection refused bymail2.nai.net.
451 nana1@earthlink.net... reply: read error from slovakia-c.it.earthlink.net.
451 bearshag@cconnect.net...timeout waiting for input during client greeting
451bearshag@cconnect.net... reply: read error from berlin.cconnect.net.
bearshag@cconnect.net... Deferred:Connection reset by berlin.cconnect.net.
... while talking to julius.bright.net.: >>> MAIL From:<RIGENWEB-L-request@rootsweb.com> SIZE=925
<<< 553 <RIGENWEB-L-request@rootsweb.com>
... Access denied,name rootsweb.com
RIGENWEB-L-request<@rootsweb.com unknown to DNS501 lululand@bright.net... Data format error
This is a problem at the subscriber's ISP. Nothing you can do about it.  It may be temporary, it may not.

Do you remove them manually?  If Smartlist is not going to do it, YES, as this problem is not necessarily going to resolve itself.


From:      Mail Delivery Subsystem <MAILER-DAEMON@mail.alphalink.com.au>

Subject: Returned mail: unknown mailer error 1
To: <GENANZ-L-request@rootsweb.com>
The original message was received at Tue, 31 Mar 1998 09:39:53 +1000 from bl-30.rootsweb.com [207.113.245.30]
----- The following addresses had permanent fatal errors -----
<tweedle_dum@alphalink.com.au>
<tweedle_dee@alphalink.com.au>
<blinky.bill@alphalink.com.au>
----- Transcript of session follows -----
deliver: delivery error on host mail.alphalink.com.au.
Delivery to these addresses failed:
tweedle_dum Reason(s) for failure: "tweedle_dum": No such user deliver:
can't open /var/adm/deliver.errlog for writing: No such file or directory
554 <tweedle_dum@alphalink.com.au>...unknown mailer error 1 deliver: invalid effective uid 0!?deliver: invalid
real uid 0!? deliver: can't open/var/adm/deliver.errlog for writing: No such file or directory
554 <tweedle_dee@alphalink.com.au>... unknown mailer error 1 deliver: delivery error on host
mail.alphalink.com.au.Delivery to these addresses failed: blinky.bill Reason(s) for failure: "blinky.bill": No such
user deliver: can't open /var/adm/deliver.errlog for writing: No such file or directory
554 <blinky.bill@alphalink.com.au>... unknown mailer error 1
This is a problem at the subscriber's ISP. Nothing you can do about it.  It will probably be temporary, it may not. Note that it is a dead giveaway when you see a number of addresses all having problems at the same time from the same place that a configuration has gone skewy.  We will take it for granted that the problem is at the receiving end ;-) unless they can prove otherwise which they can rarely do.

Do you remove them manually?  If Smartlist is not going to do it, YES, as this problem is not necessarily going to resolve itself in a hurry.

What follows is another example of the sorts of errors you might get.  Same scenario with what you can do about it though.

From:      Mail Delivery Subsystem <MAILER-DAEMON@Zeus.es.co.nz>

To: <GENBRIT-L-request@rootsweb.com>
Subject: Returned mail: unknown mailer error 128
----- The following addresses had permanent fatal errors -----
<burke@es.co.nz><wills@es.co.nz>
----- Transcript of session follows -----
mail: can't load library '/lib/libc.so.4.6.27' Out of memory mail: can't load library '/lib/libc.so.4' Out of memory mail: can't find library 'libc.so.4'
554 <burke@es.co.nz>... unknown mailer error
128 mail: can't load library '/lib/libc.so.4.6.27'
Out of memory mail: can't load library '/lib/libc.so.4'
Out of memory mail: can't find library 'libc.so.4'
554 <wills@es.co.nz>... unknown mailer error 128

 

Subject:   Returned mail: Remote protocol error

From: Mail Delivery Subsystem <MAILER-DAEMON@Symbios.COM>
To: <SHERMAN-L-request@rootsweb.com>
The original message was received at Sat, 11 Apr 1998 20:20:56 -0600 from bastion.symbios.com [204.131.201.2]
----- The following addresses had delivery problems -----
ttt@wic1.ks.symbios.com (unrecoverable error) (expanded from: tic.tac.toe<@symbios.com>)
----- Transcript of session follows -----
554 ttt@wic1.ks.symbios.com... Remote protocol error
Another case where there is a problem with the configuration of the remote system's mail. This remote system doesn't like something about the way things are being received (the protocol) and it just shoos away things that it cannot cope with (sort of reminds one of government 'pedanto'-crats ).  This is an internal problem at this sit and their own system cannot talk to itself properly (now what did I say about government?). It may be a temporary glitch and it may be a sign of bigger badder things for that ISP

Do you remove them manually?  If SmartList is not going to do it and it is a continuing problem, YES, as this problem is not necessarily going to resolve itself. This is another case of where one might be able to write to the site's postmaster. If not, list admins can forward the bounce notice to listmaster@rootsweb.com.



FATAL Problems existing ... (digests)
From:      Mail Delivery Subsystem <MAILER-DAEMON@rootsweb.com>

To: <GENANZ-D-request@rootsweb.com>
Subject: Returned mail: mime8to7: Content-Type: "multipart/alternative;": missing boundary
The original message was received at Tue, 17 Mar 1998 15:20:43 -0800 (PST)from slist@localhost
----- The following addresses had permanent fatal errors -----
mickey@www.ats.com.auminnie@energex.com.au
----- Transcript of session follows -----
554 mime8to7: Content-Type: "multipart/alternative;": missing boundarymickie@www.ats.com.au
... Deferred: Connection refused by www.ats.com.au.451 minnie@energex.com.au
... reply: read error from bastion.energex.com.au.minnie@energex.com.au
... Deferred: Connection reset by bastion.energex.com.au.
This is an unusual one and if you get one, you will usually get more than one, and it will only ever happen with digest subscriptions. Also this is an error that is the fault of a hiccough in the SmartList software at RootsWeb.

RootsWeb sends out its digests in MIME form and one of the components of a MIME digest is a boundary marker so that MIME-enabled software can pick the break in the messages.  Well once in a blue moon there is obviously some conniption in the construction of the digests and it so happens that one of these boundary markers is left out.  Now generally this is not a problem except there are some MIME-aware SERVERS out there and they sense that the digest is 'broken' and return it.  As it does not happen too often it is not a problem for you,and as list admin there is nothing that you can do anyway.  If the subscribers know that they are missing the digest they are able to retrieve from the archives and it won't be a problem (MIME-wise) as retrieving a digest from the archive nullifies the effect of the MIME.

Do you remove them manually?  No,this error happens so rarely from RootsWeb's digests and as it was a problem with the mail itself, just delete this bounce.


TRANSIENT Problems existing ...
From:      Mail Delivery Subsystem <MAILER-DAEMON@rootsweb.com>

To: <GENANZ-D-request@rootsweb.com>
Subject: Returned mail: Cannot send message within 4 hours
**************************************************
THIS IS A WARNING MESSAGE ONLY
** YOU DO NOT NEED TO RESEND YOUR MESSAGE **
**************************************************
The original message was received at Tue, 17 Mar 1998 19:36:48 -0500 (EST)from kok-119.netusa1.net [206.150.216.119]
----- The following addresses had transient non-fatal errors -----
<headbangers@music.ferris.edu>
----- Transcript of session follows -----
<headbangers@music.ferris.edu>... Deferred: Operation timed out with music.ferris.edu.
Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old
Final-Recipient: RFC822; headbangers@music.ferris.eduAction:
delayed status: 4.4.1Remote-MTA: DNS; music.ferris.edu
Last-Attempt-Date: Tue, 17 Mar 1998 23:46:32 -0500 (EST)Will-Retry-Until: Sun, 22 Mar 1998 19:36:48 -0500 (EST)
This bounce is another one of those pesky bounces that you hate to put up with as a list admin as for you they are just irritating.Here the mail is not able to be delivered within X hours of being received at this server, then server says that it will try again and when it will keep trying until.  The defaults here are trying every day for for five days, at that time you usually get this error Returned mail: Cannot send message within 5 days if it has been unsuccessful.

Do you remove them manually?  If Smartlist is not going to do it and it is a continuing problem, YES



How can you help?

If you get an error message that is not listed, please forward the bounced message with annotations to the webmaster so that it can be added to this list.

Prepared on behalf of Team-RootsWeb by Andrew Billinghurst (with contributionsfrom Tim, Vicki, Peggy, Susan and others).