> I found out that aol.com is not compatible with status codes as
> defined in RFC 1893. As you can see in the sample bellow, the
> transcript of session indicates a 'User Unkown' whereas "Status"
> field of the delivery-status indicates a Success (2.0.0). This
> completely alter the analysis of error reports !
>
> Did anyone already observe such problems with other ISPs ?
Yes; welcome to my personal hell. After discovering that /only/ Sendmail
actually implements the RFC1893 spec completely correctly, I gave up and
wrote a temporary method for Listar that just parses certain specific
bounce formats, and then tries to determine the information if it is not a
bounce format it recognizes.
I am currently trying to come up with a much more general way that will
work with the busted MIME information I have seen in several bounce
messages. I would fold that parser into Listar again, but I would also be
happy to work with others to make a bounce parser that is more
general-purpose and could be folded into other packages as well.
--
Jeremy Blackman - lo...@maison-otaku.net / lo...@listar.org / jer...@lith.com
Lithtech Team, Monolith Productions -- http://www.lith.com
Listar Developer -- http://www.listar.org
We are developing a non-delivery reports analyzer for Sympa MLM.
This module already extracts bouncing address and error status for more
than 90% of "bounces". The goal is to provide information about
bouncing addresses within a web interface (WWSympa) for list-owners.
Analysis is mainly based on RFCs 1891-1894 defining a MIME extension
for Delivery Status Notifications, allowing (automatic) identification
of recipients and error status.
RFC 1893 defines Mail System Status Codes to be used by MTAs.
Eg: 5.1.1 => User unknown ; 5.2.2 => Mailbox full
I found out that aol.com is not compatible with status codes as
defined in RFC 1893. As you can see in the sample bellow, the
transcript of session indicates a 'User Unkown' whereas "Status"
field of the delivery-status indicates a Success (2.0.0). This
completely alter the analysis of error reports !
Did anyone already observe such problems with other ISPs ?
--------------
Olivier Salaün
Here is a sample Delivery Status Notification :
Content-Type: multipart/report; report-type=delivery-status;
boundary="BOUNDARY"
--BOUNDARY
----- Transcript of session follows -----
... while talking to xxx.mail.aol.com.:
>>> RCPT To:
<<< 550 MAILBOX NOT FOUND
550 ... User unknown
--BOUNDARY
Content-Type: message/delivery-status
Reporting-MTA: dns; listes.cru.fr
Arrival-Date: Thu, 6 Jan 2000 09:22:43 +0100 (MET)
Final-Recipient: rfc822; y...@aol.com.
Action: failed
Status: 2.0.0
Diagnostic-Code: smtp; 250 OK
--BOUNDARY
Content-Type: text/rfc822-headers
--BOUNDARY