Re: [Asrg] Re: Yet another attempt to fix forwarding

On Jan 30, 2008, at 3:15 PM, Frank Ellermann wrote:

> Douglas Otis wrote:
>
> > these records may also be applied against the Purported Responsible  
> > Addresses
> Receivers can also apply them to the Message-ID and use the results  
> as entropy source for /dev/random, but apart from a NOT RECOMMENDED  
> statement in RFC 4408 this is unrelated to SPF.
> It's also unrelated to "forwarding" (see subject), and how RFC 821  
> made sure that "forwarders" must take the responsibility for their  
> actions (= by adding their host to the reverse path).
SPF advocates decided _not_ to adopt the revised record format that  
specifies scope.  Scope clarifies applicability without a separately  
published declaration specific to Sender-ID.  Most don't, as Sender-ID  
declares separate publication to be unnecessary.  Concerns seemed  
focused upon how adoption of revised records would be perceived, and  
whether Sender-ID might then assert a leadership role.  As it is now,  
Sender-ID declares older SPF versions to be a valid a means to  
indirectly authorize providers based upon the PRA, SPF recommendations  
not withstanding.
> > The difference between the provider and the provider's customer is  
> > extremely important.
> Not for the reverse path, this was just a route to a mailbox of the  
> "sender", a sender(_at_)host mailbox for MAIL FROM this host.
This still represents requirements for the provider's customers which  
might extend to the PRA, your assurances not withstanding.
> > When access depends upon an identity's indirect declaration of  
> > their authorized providers by way of address, privacy protection is  
> > clearly reduced.
> The envelope sender address is used for non-delivery reports, FWIW  
> it can be postmaster(_at_)host or postmaster+crypto(_at_)host or crypto(_at_)host,  
> this has nothing to do with "privacy protection".  If somebody can't  
> receive mail he has no business to send mail, that's as it always  
> was, and if you want real anonymity this needs considerably more  
> effort than using a forged envelope sender (or 2822 PRA) address.
SPF records will never be revised to include scope, obsolete dangerous  
macros, or segregate IPv4 or IPv6 record sets.  Restrictions based  
upon the PRA and MAIL FROM are being done in lieu of requirements  
based upon a provider's stewardship.  Well managed MTA should permit  
their customer's latitude in the choice of addresses.  Call back  
validation represents a similar menace.  SPF specifically sets out to  
restrict choice.  Restrictions placed upon customers are better at  
diverting complaints than controlling abuse.
> > When access depends upon an identity's declaration of authorized  
> > providers, the means for making this declaration resolves to the  
> > provider's customer, and not the provider.
> Nobody is forced to declare which IPs they consider as permitted or  
> forbidden for mails sent by them.
This depends upon acceptance requirements.

> And if they do you can still use "your" 2822-From address where it  
> pleases you as far as SPF is concerned.  This won't work for PRA or  
> SSP, but that's not my problem while talking about SPF and SMTP.
This remains a problem that SPF failed to confront, your efforts to  
sweep this under the rug not withstanding.
> > There are perhaps a few hundred thousand major providers, and yet  
> > there are millions of individual's email domains in use.
> Yes, they can combine providers as they see fit in their policy, or  
> never care about it if they have no problems with backscatter.
This assumes SPF records are used in an innocuous manner.

> > EHLO validation is yet another optional "feature" of SPF
> Nope, it's RECOMMENDED, not "optional".
Okay, but would there be a need to recommend something that is  
required?  SPF's sizeable overhead and dubious results doesn't help in  
this case either.
> Does SPF really threaten your commercial "anti-spam" interests so  
> much ?  *Brilliant*
Actually, SPF threatens all services and is not specific to "anti- 
spam".  DDoS remains a real concern imperilled by poorly considered  
protocols (SPF should not have been published, even as experimental  
without significant changes IMHO).
Making a difference is not impossible, and there is an effective means  
that affords greater freedom.  Hold providers accountable.  Require  
SMTP clients to confirm their domain's authorization.  This removes  
questions related to which individual is sending the message.  There  
is S/MIME and OpenPGP when identifying an individual is important.
Exchanging DKIM keys with providers represents another bad practice.   
Authorizations should be done by name, not address or key exchange.   
In addition, authorizations should not depend upon the identity used  
by the individual sending the message.  With respect to DKIM, the i=  
parameter should be allowed to be opaque or anything at all, even when  
a provider asserts "ALL" or "STRICT" signing policies.  Controlling  
abuse in an effective manner is the best way to eliminate a need for  
commercial anti-spam efforts.  There are better things to do, after  
all. : )
-Doug










_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg