|
Re: Request for Input on the meaning of "pass".
2005-06-02 16:52:31
Mark,
Thank you for the opportunity to provide input.
As an SPF publisher, I have no real problem with either wording though I
tend toward your option 2. Caveat emptor: we operate our own in house
email servers with server software from an SPF savvy supplier. As such, we
are reasonably comfortable, short of a security compromise from a hacker or
worm, that the mail we issue from our SMTP servers, we intended to
issue. Just so, the mail we bounce, probably should be bounced. So far,
with SPF there have been no problems around here with erroneous bouncing or
drops when configurations are properly set.
The above said, I think that I can see where others might have legitimate
concerns with option 1.
Reading though the really great messages prior to my own, I have two
comments for Julian Mehnle -
you almost won me over with your argument, right up to this paragraph:
|Again, what's the difference between one being authorized to use a domain
|and one's use of a domain being authentic? Are you saying that there are
|people who are authorized to use a domain, but whose use of that domain
|isn't authentic? In other words, are you saying that the concept of
|authorizing people to forge a domain is meaningful?
I think the resistance to your argument and other like arguments tends to
come from an *unauthorized* use (e.g., a worm/virus infection or deliberate
employee sabotage) that may happen without the knowledge and/or the
permission of a domain owner who is otherwise certain about their SPF
record (to the degree they publish as -all). While the owner might control
both the domain and the DNS SPF record, they are not omnicent and cannot
stop all internal and external network attacks. In publishing a -all, I
want people to know that if they receive mail from the IPs published, it
did come from an SMTP server allowed to send email for the domain, but make
no conclusions about the validity of the sender, because it is conceivable
that we were hit by something or someone bent on doing us harm. On the
other hand, if you receive a message claiming to be from us, but is not in
our published IP set, then, by all means, absolutely dismiss the message as
a forgery and don't ever let that forged message get presented to a human.
and also for Julian:
|So then what are the "Neutral" (?) and "SoftFail" (~) results for?
To me, Neutral (?) screams out "don't conclude anything about this message
because I am not at all convinced of the veracity of my published record or
SPF is important to me, but my environment won't let me publish a SoftFail
or -all".
SoftFail (~) says to me, "I am reasonably certain about my SPF record, but
I am still testing or temporarily something has changed in my network and I
don't want you to lose any mail because of that temporary change. When it
is permanently changed or reversed, I'll go back to my more authoritative
(-all) record".
Bottom line for me as a publisher: I tend to agree with Dennis Willson's,
Graham Murray's and Mark of asarian-host.net's takes on SPF - go with option 2.
Whatever the final outcome in this debate, I would ask that the council
please use prudent judgement in selecting the wording that most tends to
serve the interest of getting SPF more widely adopted as a valuable tool to
prevent domain name identity theft in email. In the final analysis, I
think that is why most early SPF publishers adopted SPF in the first place.
Best,
Alan Maitland
WebMaster(_at_)Commerco(_dot_)Net
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/
At 11:21 AM 6/2/2005, you wrote:
There is an issue regarding "pass" that we, the SPF Council, would like to
have your opinion on.
2.5.3. Pass
A "Pass" result means that the client is authorized to inject mail
with the given identity. Further policy checks, such as reputation,
or black and/or white listing, can now proceed with confidence in
the identity.
In a nutshell, we would like to solicit your position on whether SPF can
be said to 'authenticate' the identity on "pass", or wether the connecting
client can only be considered 'authorized' to use the identity. Where
"authentic", in this context, means: "not forged".
Roughly, there are two main positions:
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".
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".
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.
We feel the issue is important; especially so if reputation-checks are to
become a more pronounced part of SPF.
What "pass" really means/implies touches upon the very core of SPF.
Therefore, instead of ruling on it immediately, we decided to bounce the
issue back to the spf-discuss forum, along with the cordial request for
you to speak out on the matter at your earliest convenience. Preferably
before Monday.
The matter was discussed by the SPF Council itself; and you can review the
log of the last Council meeting at:
http://www.schlitt.net/spf/spf-council/2005/06/02_irc_log.html
Thank you for your cooperation.
- Mark
System Administrator Asarian-host.org
---
SPF Council member
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
|
|