Re: Re: patch

wayne wrote:
> In <427FBB04(_dot_)6050805(_at_)redhat(_dot_)com> Chuck Mead 
> <csm(_at_)redhat(_dot_)com> writes:
>
>
> > --- spf-classic/draft-schlitt-spf-classic-01pre5.txt.orig       2005-05-09 
> > 14:05:28.096096688 -0400
> > +++ spf-classic/draft-schlitt-spf-classic-01pre5.txt    2005-05-09 
> > 15:15:30.637213328 -0400
> > @@ -42,7 +42,7 @@
> > Abstract
> >
> >    E-mail on the Internet can be forged in a number of ways.  In
> > -   particular, existing protocols place no restriction in what a sending
> > +   particular, existing protocols place no restriction on what a sending
> >    host can use as the reverse-path of a message.  This document
> >    describes version 1 of the SPF protocol, whereby a domain can
> >    explicitly authorize the hosts that are allowed to use its domain
> > @@ -173,13 +173,13 @@
> >
> >    The current e-mail infrastructure has the property that any host
> >    injecting mail into the mail system can identify itself as any domain
> > -   name it wants.  Hosts can do this at a variety of levels: in
> > +   name it wants to.  Hosts can do this at a variety of levels: in
> >    particular, the session, the envelope, and the mail headers.  While
> >    this feature is desirable in some circumstances, it is a major
> >    obstacle to reducing Unsolicited Bulk E-mail (UBE, aka "spam").
> >    Furthermore, many domain name holders are understandably concerned
> >    about the ease with which other entities may make use of their domain
> > -   names, often with the intent to impersonate.
> > +   names, often with malicious intent.
> >
> >    This document defines a protocol by which domain owners may authorize
> >    hosts to use their domain name in the "MAIL FROM" or "HELO" identity.
> > @@ -326,8 +326,7 @@
> >
> >    An SPF compliant domain MUST publish a valid SPF record as described
> >    in Section 3.  This record authorizes the use of the domain name in
> > -   the "HELO" and "MAIL FROM" identity, by some sending MTAs, and not by
> > -   others.
> > +   the "HELO" and "MAIL FROM" identity, by MTAs it specifies.
>
> I applied all of these.
>
>
> > @@ -406,19 +405,10 @@
> >    (see [RFC1983]).  These archaic features have been maliciously used
> >    to bypass security systems.
> >
> > -   This authorization check SHOULD be performed during the processing of
> > +   This authorization check MUST be performed during the processing of
> >    the SMTP transaction that sends the mail.  This allows errors to be
> >    returned directly to the sending server by way of SMTP replies.
> >
> > -   Software can also perform the authorization after the corresponding
> > -   SMTP transaction has completed.  However there are two problems with
> > -   this approach: 1) It may be difficult to accurately extract all the
> > -   required information such as client IP address and HELO domain name.
> > -   2) If the authorization fails, then generating a non-delivery
> > -   notification to the alleged sender is problematic due to the large
> > -   number of forged e-mails on the Internet today.  Such an action would
> > -   go against the explicit wishes of the alleged sender.
> > -
> > 2.5  Interpreting the Result
> >
> >    The check_host() function returns one of several result codes.  This
>
> I did not apply this one.  As discussed on #spf, Chuck feels very
> strongly about requiring SPF being done during the SMTP transaction
> and not during later processing, such as SpamAssassin and other
> filters are doing.
>
> I'm interested in opinions from others.
And I 100% agree with Chuck.  There are oodles of programs that run 
after SMTP, all causing mail suppression and/or bouncing issues.
A process that rejects at SMTP guarantees good mail is *always* properly 
informed of rejection, and bad mail (e.g. connections from spammer 
drones) don't bounce around the rejections.
I am tired of receivers not getting their mail because the email was 
incorrectly identified and the sender never gets informed of the denied 
delivery.  And I am tired of the client side filters that suppress the 
email AND respond because then the forgeries...
Rejecting at SMTP is *the* answer to when to reject.

Terry

> -wayne
>
> -------
> Sender Policy Framework: http://spf.pobox.com/
> Archives at http://archives.listbox.com/spf-discuss/current/
> Read the whitepaper!  http://spf.pobox.com/whitepaper.pdf
> To unsubscribe, change your address, or temporarily deactivate your subscription, 
> please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
--
Terry Fielder
terry(_at_)greatgulfhomes(_dot_)com
Associate Director Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
Fax: (416) 441-9085