Re: [BULK] Re: SORBS contact

[Michelle Sullivan <matthew () sorbs net>]

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/