spf-discuss
[Top] [All Lists]

Re: Request for Input on the meaning of "pass".

2005-06-03 16:28:23
Julian,

At 06:07 AM 6/3/2005, you wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alan, thanks for your comments.

Alan Maitland wrote:
> 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.

I am not saying that I want to make "Pass" an absolute statement.  As I
said, not even PGP can make absolute statements.

But SPF is not really worse than PGP with regard to confidence, but just
with regard to granularity.

Again, I would agree with you, but as Mark and some others have either essentially stated or implied, there may be legal ramification in how wording in a specification is expressed and thus consequences to those who implement said specification.

Please not that I am not an attorney, so my thoughts here especially fall into the "I reserve the right to be wrong". That said, arguably, only the party at the originating responsible IP that does any damage should be held accountable and face the consequences of their acts or actions. Unfortunately, at least in America, that is nearly never the case. In the US, lawyer 101 teaches American attorneys to sue everyone even remotely involved in a case. The logic goes that some on the list of "everyone" being named as defendants will want to settle if they believe that there is a remote chance the plaintiff in an action may prevail or they simply wish to stay out of the limelight. If you employers are a large ISP, your legal department is going to be very interested in anything you choose to accept responsibility for on behalf of the ISP just because they don't wish to have their companies in such situations.

The big difference between things like SPF and PGP is that PGP is kind of a covenant between the sender and the recipient and thus has nothing to do with the transport infrastructure. SPF on the other hand, when published by ISPs themselves, is directly pointing to the infrastructure and thus by making absolute claims of responsibility other than the obvious and provable (e.g., why, yes, 192.168.22.22 is indeed our outbound email server, but we can't say anything more or no, 192.169.243.231 is certainly not our email server for domain X, so ignore anything they say that is otherwise the case), may be considered an untenable claim and thus unacceptable to an ISPs legal department.

I think that one of the really terrific features of SPF as it exists today is that, as a publisher, all you are claiming as regards absolutes is that an entity absolutely did not have permission to send under a domain name for which you have DNS control. That simplicity makes SPF a technological thing of beauty as regards domain identity theft. Something even a lawyer could love.

> > 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.

Exactly, in _practice_, it doesn't make sense to say that the use of a
domain is unauthentic just because it was some virus on my PC that sent
the message.  After all, messages sent by a spammer deliberately using
some software on his own machine (which is properly authorized through SPF
to use the spammer's own domain) would be considered authentic, too,
wouldn't they?

Again, I think the semantics of your argument, only as it regard possible legal liability, is the core of most of the objections you seem to be getting on this question.

> 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.

Agreed.

> As regards the SMTP resources under the domain holder's control, [...]

Also agreed.

But what about the SMTP resources that are neither under the domain owner's
nor under the forger's control (typically shared MTAs)?

Should domain owners assert "Pass" for those MTAs, even though the MTAs may
not prevent cross-user forgery?

Actually, I was thinking about this a bit and wonder if the SPF semantics that Frank Ellermann posed today actually exist in the specification (IN SPF "v=spf1 op=auth +a ?include:example.com -all").

If such semantics do exist, that is great because then the answer to your question is perhaps: it is all in how a publisher might publish their SPF record.

For example, in a case where you are comfortable in asserting absolutes about email servers that should be allowed to send messages and not for some others, you could say "v=spf1 ip4:192.168.1.1 ip4:192.168.1.2 ~include:upline.isp.tld -all", which I would interpret to mean "if you got email claiming MAIL FROM: domain that came from 192.168.1.1 or 192.168.1.2, then yes, the message can come from domain through those servers that were authorized to send out bound mail for it, so presume SPF passed in a big way. On the other hand, if you got mail from upline.isp.tld's published SPF records, then you can presume that SPF passed, but perhaps with not the same level of veracity as with the two IP addresses, perhaps because upline.isp.tld might allow cross user forgery."

If the SPF specification allows for semantics as in the example above, I think that might address your question.

> 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.

Of course a domain owner won't vouch for its users (i.e. for all the
actions of its users).  But it should vouch speficially for the use of the
domain by any of its users.  And the older draft- mengwong-spf-* specs
actually do say that:

|      Pass (+): the message meets the publishing domain's definition of
|      legitimacy.  MTAs proceed to apply local policy and MAY accept or
|      reject the message accordingly.

Wayne has argued that "declaring legitimacy" does not mean "accepting res-
ponsibility", but _if_ "authenticity" means "knowing who is responsible",
then based on my dictionary (which says that both "legitimate" and
"authentic" mean "genuine" or "not false") I can't follow his logic.

When something seems that should be apparent and yet somehow is not, but rather seems really strange, the odds are excellent that there are one of two possible reasons. 1) A lawyer in the woodpile. 2) Money.

My guess is that Wayne's concerns go to addressing reason 1. Which, BTW, I believe is a very sound concern and reason for argument against statements in any specification that may return to bite those who may choose to implement said specification.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCoEf4wL7PKlBZWjsRAiz0AJ9MWrwgkiqalXwJ8ZubZO3vV+2xkACgymBp
qdZphLZfxNgYtS4V/J4AxYo=
=i/K8
-----END PGP SIGNATURE-----

Again, I hope I have clarified.  I reserve the right to be completely wrong.

Best,

Alan Maitland
WebMaster(_at_)Commerco(_dot_)Net
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/