[Asrg] Re: Yet another attempt to fix forwarding

["Frank Ellermann" <nobody at xyzzy.claranet.de>]

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).

> 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.

> 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.

> 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.

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.
 
> 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.

> EHLO validation is yet another optional "feature" of SPF

Nope, it's RECOMMENDED, not "optional".  Does SPF really threaten
your commercial "anti-spam" interests so much ?  *Brilliant*

 Frank


_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg