-----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.
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?
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?
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFCoEf4wL7PKlBZWjsRAiz0AJ9MWrwgkiqalXwJ8ZubZO3vV+2xkACgymBp
qdZphLZfxNgYtS4V/J4AxYo=
=i/K8
-----END PGP SIGNATURE-----