William Herrin wrote:
On Fri, Jul 29, 2011 at 2:46 AM, <Valdis.Kletnieks@vt.edu> wrote:
And you might want to fix it, since your users will never get a bounce notice from any RFC-compliant mailer - even if they *wanted* to know that their mail wasn't delivered. <> is the RFC-standard way to denote "this mail is a bounce report or other programmatically generated mail, and if it bounces itself, do *not* generate another bounce, as that may start a bounce loop".
Correction: It's a standard way to denote that "this mail is a bounce report."
Umm no... As has been pointed out by others, but in another section (maybe another RFC) it says that the null return path should be used when a return message is not required, not desired, or it is from an automated system or you wish to avoid mail loops (with particular reference to bounce messages and mailing lists.) The registration email has a null return path because people will put in forged addresses and we don't want them to do that in the first place, and if they do it, we certainly don't want any auto-responder from replying or it going to a mailing list (most mailing list software prevent delivery of null return path mail to the list members) - seems the like most responsible and desired setup.. which is why I chose it. Note (to answer another mail in this thread): MAIL FROM:<> and 'From: <devnull@sorbs.net>' in the headers to be completely within standards (previously it used in the headers as well which is a violation of an RFC - I forget which one.) Michelle PS: Baracuda are not the only ones, Ironport has an option for it as well - but I believe the default in Ironport is 'Off' for bounce control. -- Vulnerabilities are weaknesses associated with an organisations assets that maybe exploited by a threat causing unwanted incidents. http://www.mhix.org/