On Thu, Jun 02, 2005 at 05:21:08PM +0000, Mark wrote:
Roughly, there are two main positions:
You mean: Roughly two main positions are recognized by the council, right?
1): If the cross-user forgery thing is the only issue that keeps us from
asserting authenticity, we should instead find a way to make it clear to
publishers that they must assume responsibility if they authorize an MTA.
Therefore, the following wording remains applicable:
"can now proceed with confidence in the identity".
Responsibility: yes. Authorization: yes. Confidence: yes.
Now get rid of authentication as this has nothing to do with it.
2): Even if a publisher chooses to authorize an MTA patched to prevent
cross-user forgery, then, without adding to the spec, there is still no
way for a receiver to know this; so that "pass" can really only mean:
"can now proceed with confidence in the legitimate use of the
identity".
Cross customer forgery is mostly irrelevant.
The only thing SPF can be used for is to express confidence, trust,
in a certain host. The domain owner is putting his reputation on
stake. Does the domain owner trust a certain host or not.
Should any issue arise, and should my domain be forged, do I have
sufficient trust in my provider to handle this issue and kill the
offending user, can I claim damages and so forth (this of course
for the "+smtp.example.com" case).
In the same vein, we would also like to know whether the domain owners
among you assumed that receivers would take SPF-verified identites as
'authentic' (position 1) or just as 'authorized' (position 2) when they
published their policies.
I think I made my position clear, see above.
We feel the issue is important; especially so if reputation-checks are to
become a more pronounced part of SPF.
Yes, clear. But what has this to do with authentication? Nothing!
Authentication can lead to authorization (or not). This does not
mean that authorization necessarily implies authentication.
If apple is a fruit then all fruit is an apple? Don't think so.
1) Domainowner.example.ORG expresses trust in smtp.example.COM
2) smtp.example.COM is not worth this trust
3) abuse is reported to abuse(_at_)domainowner(_dot_)example(_dot_)ORG
4a) domainowner.example.ORG adapts
5a) smtp.example.COM is no longer allowed to send ad domainowner.example.ORG
6a) domainowner.example.ORG uses another box to send its mail
7a) domainowner.example.ORG's reputation stays on the good side
or
4b) domainowner.example.ORG does nothing
5b) abuse continues
6b) domainowner.example.ORG's reputation goes down the drain
Note that nowhere authentication occurs yet reputation works!
Alex