Interpreting 'Returned Mail'
or Dealing with Bounces
Returned mail or `bounces' can be the bane of a list administrator's email day [well that is after spam, the complaints about spam and of course everything else ;-) ] but they can also be used to help manage the problems that exist and gain that little bit more knowledge.
Error messages can emanate from either the RootsWeb server, the receiving server (ISP) or from some server along the path of transports. This can also help explain why it may have been working before and it is not now, and if you are a slightly more experience list administrator it helps to workout where to complain to if you wish to do something to resolve the problem.
Tim the Guru says:- If foo.net were refusing mail from RootsWeb due to failures, the bounces that the list administrator gets will be from MAILER-DAEMON@rootsweb.com. Bounces from MAILER-DAEMON@foo.net, means that this system actually accepted the mail from RootsWeb but then decided not to or that it could not deliver the mail.
The dominant software used for mail delivery is SENDMAIL (it is also the software that RootsWeb uses) and the errors/comments that we see are 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 theirinfancy. 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). Here for these others.
Glossary of terms
Subject: Returned mail: blah blah blah of bounced message
FATAL problems existing ...
- Returned mail: Service unavailable
- Returned mail: Too many hopsxx (25 max)
- Returned mail: Cannot send message within X days
- Returned mail: Can't create output:
- Returned mail:Cannot reopen DB database
- Returned mail: Insufficient permission
- Returned mail: User unknown
- Returned mail: Bad usage
- Returned mail: Host unknown
- Returned mail: @gte.net... user address required
- Returned mail: Local configuration error
- Returned mail: mx2.raex.com.config error: mail loops back to me (MX problem?)
- Returned mail: Data format error
- Returned mail: unknown mailer error 1
- Returned mail: Remote protocol error
FATAL problems existing ... (digests)
TRANSIENT problems existing ...
Other mail software and specially designed responses from ISPs
- Message status - opened
- Mail System Error - Returned Mail
- cc:Mail Link to SMTP Undeliverable Message
- mail failed, returning to sender
- Message rejected by system
- Non deliverable mail
- Delivery failure
- Delivery Notification: Delivery has failed
- Failed mail
- Undeliverable message
Glossary of terms
- Permanent fatal error - this mail did not get through and will never get through and the server has given up.
- Transient non-fatal error - this mail did not get through, however the server will try again (it usually states when and for how long). When these times and tries run out then you should get a permanent fatal error (qv)
- Final-Recipient: rfc822; email@example.comAction: failedStatus: 5.1.2Remote-MTA: dns; nethost.orgLast-Attempt-Date: Fri, 27 Mar 1998 11:00:15 +1100 (EST)
When a MIME package is returned to you in a bounce, you should find that one of the parts of the bounce package will be labelled Final Recipient: rfc822. What you will find enclosed in this little bundle is the information that will tell you what happened (or didn't happen), who the mail was actually to and when. This info should help in your problem solving.
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.