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(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg