Seth Goodman [sethg(_at_)GoodmanAssociates(_dot_)com] wrote:
From: Julian Mehnle
Seth Goodman [sethg(_at_)GoodmanAssociates(_dot_)com] wrote:
Hey, I agree with both of you on this. This is where SPF started
and I think it's still the right approach. Authenticate the 2821
address first, and then hope that the domain owner enforces
submission rights and publishes that fact to allow you to look for
equivalence of 2821 and 2822 sender addresses.
I thought one of the main points of RFC 2822 checking was to avoid the
forwarding problems of RFC 2821 checking. If you do both, you might
get the worst of both worlds.
I am not, not, not {...} advocating the dual-purposing of records
written for a single, clear purpose.
[...]
What I was advocating is not an option for very many people, because as
Frank has correctly pointed out, the "enforce submission rights" part
of RFC2476 only covers the return-path and is optional at that. While
some ISP's enforce the MAIL FROM: submission rights, I've yet to hear of
one who actually adds a Sender: header when the From: does not match
MAIL FROM:. That's not even a SHOULD in the RFC, it's a MAY, so don't
hold your breath.
Now, if you happen to run your own mail server (or ISP) and you _do_
enforce your users' use of both 2821 MAIL FROM: and 2822 From:/Sender:,
you _should_ be able to publish the fact that you enforce this strict
sender policy. [...]
This is not using any existing spf1 record for a purpose that was not
intended. [...] It requires the domain owner who runs a particularly
strict operation to actively publish an additional modifier ("eh"
suggested by William for "equivalent headers") that informs recipients
of their strict outgoing controls.
Ok, so I misunderstood you. I actually think voluntarily enforcing
2821/2822 equivalence and defining this "eh" modifier is a very good idea!