Re: Request for Input on the meaning of "pass".2005-06-03 02:48:57Julian, At 06:25 PM 6/2/2005, you wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alan Maitland wrote: > 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). When you are saying "*unauthorized*", do you mean that abuse of a user's access to a domain identity (e.g. MTA credentials) without the user's consent should be considered as "unauthorized" with regard to SPF? Does that mean that no IP addresses should be _authorized_ that could, ever, potentially emit mail that "abuses" the domain? Or are you saying, like Dennis Willson, that mail sent from a legitimate user's machine by a virus should be considered authorized, but not authentic? Yes, I am agreeing with Dennis Willson, but I also think that an inability to absolutely authenticate / authorize goes beyond just virus scenarios. I pretty much agree with most of what you have said, however, the case of an internal virus or an employee saboteur is a foreseeable and reasonable scenario, so I think that it may not be logical to make absolute statements about authentication or authorization of users for a given domain with SPF as it stands today. > 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. True, but this is not the point. Please name any _authentication_ method whatsoever that can reliable detect that a user hasn't _personally_ typed the message into the keyboard and pressed the "send" button, but that a virus on his machine sent the message. Not even PGP can do that, yet everybody seems to agree that PGP can assert authenticity. I don't see the fundamental difference, though. Yes, I see your point, but I think most of us see SPF as it stands today as a specification to protect domain reputation as regards others misusing a domain holder's domain name. SPF is granular to an IP level rather than a user level in its current incarnation. There may well be degrees of trust that some companies may wish to have associated with certain users. I think that SPF or similar DNS TXT approaches would not do well in handling that sort of thing for anything but the smallest of environments. What about "viruses" than operate with the full knowledge and intent of the user? Should not the domain's reputation be able to suffer from that? I think that would extend beyond the scope of what SPF and similar DNS TXT approaches can or should do. I don't think that one can assess the intent of the owner/operator of an infected machine using SPF. Personally, I think people who commit deliberate acts that harm others should suffer reputation damage and even face severe legal consequences based upon the actions of the payload the virus in question delivers (minimally, no matter the case, they should be sent to their rooms without dessert), however, I cannot see how SPF or similar DNS TXT approaches can address any of those issues. Or would you go so far as to challenge the concept of reputation altogether? If you mean domain reputation, I think SPF provides a very clear and reliable way to confirm to the known universe that a server sending was not authorized by the domain holder. This reality absolutely protects a domain holder's domain reputation as regards others trying to illegitimately send any messages which forge a domain holders domain name via SMTP resources under the control of the forging party. As regards the SMTP resources under the domain holder's control, I think the best one can say is that a given network device was allowed to send email using the domain in question as authorized by the domain holder. Even then that says nothing about the message content or the sender under a domain. After all, a sender of unsolicited commercial email (UCE) can certainly publish an SPF record for their domain. Should they do so and send out UCE, then it is clear they sent it via authorized servers for their domain. That is about the extent of the valid conclusions on can make here. Is it spam? SPF does not know. Was the user authorized to send? Users don't enter the picture in today's specification, so if you are asking domain holders who publish SPF records to vouch for the veracity of the entire user base by claiming they are authorized as a blanket statement, that might be a bit of an unfair expectation. Perhaps that will not be the case for future SPF versions, but I think the board is looking to produce a final document to reflect the current generally accepted and implemented SPF specification. > 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". Saying "v=spf1 ?a ?mx ?all" just for the sake of being able to publish SPF at all? What's the point of that? None, but I think that the idea of a Neutral result was intended to handle the case of no published SPF record. As I understand it, the syntax you offer above essentially says, "I published an SPF record, but what you just got is the same as if I did not publish and SPF record". Perhaps it is in there as a tool for developers or publishers to use during the testing process (e.g., a place keeper in the zone file rather than commenting out the TXT in the zone file). I thought the point of "Neutral" (?) was to be used for exactly those IP addresses which should not be rejected because they are used by legitimate users of the domain, but which cannot be considered entirely secure (e.g. shared MTAs which don't protect against cross-user forgery). What's the point of overloading "Pass" with "Neutral"'s meaning? Sometimes there exist cases where items are included in specifications for completeness sake rather than as an indication that people should want to implement the item. Arguably, Neutral might be viewed as a reserved option in the specification, in a similar spirt to the way that CONNECT is a reserved URI request method in an HTTP message as featured for your reading pleasure in RFC 2616 (HTTP/1.1). In the SPF case, publishing a Neutral (?) does not make the use wrong per se, but because it results in the same net effect as not publishing a record, it would make the use pointless. > 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". I roughly agree with that description of "SoftFail". -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCn6OSwL7PKlBZWjsRAsR+AKCLwR5ZhcNIAchAoGHoT9zPLuMV1gCgtnCk CKVgV2/f57DRPBzc4ZHGI8g= =q9+M -----END PGP SIGNATURE----- Hope I was able to clarify a bit. As always, I reserve the right to be wrong. Best, Alan Maitland WebMaster(_at_)Commerco(_dot_)Net The Commerce Company - Making Commerce Simple(sm) http://WWW.Commerco.Com/
|
|