Len, I appreciate your candidness :). I'm looking for a solution to this, and while I'm going through RFC to fully understand the implications...how do I solve this issue?
The [EMAIL PROTECTED] sends an email from our web application, the From: field is "[EMAIL PROTECTED]" and the Reply To: is "[EMAIL PROTECTED]". How do I let the end user know if there email was an NDR? Should I build a custom solution to forward the NDR's that come back to "[EMAIL PROTECTED]" and forward them to "[EMAIL PROTECTED]"? Thanks, Dan > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Len Conrad > Sent: Thursday, September 30, 2004 6:49 AM > To: [EMAIL PROTECTED] > Subject: RE: [IMail Forum] Non-Delivery Email Forward To "Reply To:" > > > >Is there a way to then have IMAIL forward an NDR to the Reply To, > >automatically? The deal is that, the "Reply To: user generates this > >email in a web application and when it doesn't get delivered > it would > >be better to let them know, rather than US - > "[EMAIL PROTECTED]". > > Sorry, logic doesn't apply here. The insanity is rampant. > Don't leave > web application coders who are working with SMTP work without close > supervision or without a system design. Knowledges a > language's syntax > does not correlate with knowledge of SMTP and DNS. > > rfc822 > > > <http://rfc.net/rfc822.html#s4.3.1.>4.3.1. RETURN-PATH > > This field is added by the final transport > system that > delivers the message to its recipient. The field > is intended > to contain definitive information about the address > and route > back to the message's originator. > > Note: The "Reply-To" field is added by the > originator and > serves to direct replies, whereas the > "Return-Path" > field is used to identify a path back to the > origina- > tor. > > While the syntax indicates that a route > specification is > optional, every attempt should be made to provide > that infor- > mation in this field. > > > more at http://rfc.giga.net.tw/rfc2822, > www.networksorcery.com, etc, etc. > > > =================== > > Web apps (form capture, etc) are innumerable offenders of RFC > by using undeliverable/unverifiable > [EMAIL PROTECTED], and other bogus return-path fields, > as well as using stupid SMTP client routines that send direct > to MXs and often retry in tight loops generating 1000's of > connections to an MX in a short period, or don't retry at > all, and that don't notify anybody of the delivery failures, > rather than the app's SMTP client relaying through an MTA. > > MXs doing SAV will reject the messages since the > [EMAIL PROTECTED] is undeliverable (MX of sender.domain > says "5xx [EMAIL PROTECTED] is unknown recipient) or > unverifiable (MX and A of sender.domain not reachable) > > Len > > _____________________________________________________________________ > http://IMGate.MEIway.com : free anti-spam gateway, runs on > 1000's of sites > > > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html > List Archive: > http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ > Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
