spf-discuss
[Top] [All Lists]

Re: [SPFTAG] - RE: [SPFTAG] - RE: No use of checking RFC2822 headers - Sender is probably forged (SPF Softfail) - Sender is probably forged (SPF Softfail)

2004-09-29 08:41:35
 <terry(_at_)ashtonwoodshomes(_dot_)com> declared:
<snip>


And in order to make SPF meaningful, we have to SHOW the verified domain to
the user, hence get rid
of "pretty names"  (or only show ones that user has ascertained is to be
displayed for a given email
address based on what is in their trusted addressbook/contact lists)



IMHO this thread has got _way_ out of line with the intent of SPF.

SPF has the _meaning_ given to it in the SPF spec.  The test results are
intended for use within the mail infrastructure, not for display to humans and
are entirely 'meaningful' when used as intended.

Please don't try to contort SPF into some kind of anti-phishing scheme.

There were technical, security and usability problems with the PRA-based
approach that was discussed in 'another place' and architecturally similar
problems would still exist with the direction you are heading in.

You cannot invite users to trust something displayed at point B which was
determined at point A without the links between B and A being themselves
trusted, or else the communiction between them being protected (e.g.
crypographically signed).

SPF tests are done at point A - where a receiving MUA is in direct contact with
the IP connection from the source being validated.

Users look at B - an MUA which will usually have one or more network links
between it and A.

Unless you are going to introduce cryptographic protection for the SPF test
result, or rule that all MUAs must trust all MTAs, no amount of ingenuity with
MUA display formats is going to give you a trustworthy system.

And if you respond that you are going to introduce an MUA with cryptographic
capability, you may almost as easily specify that the original message must be
signed by its originator and have done with the whole problem!


Chris Haynes