spf-discuss
[Top] [All Lists]

RE: Non-adoption of SPF by most-phished domains

2004-09-03 13:17:38
I have am important opinion to re-inforce...

At 11:29 AM 9/3/2004 -0500, Ryan Malayter wrote:
[AccuSpam]
Frankly I do not see this as a problem.  If the domain for 
envelope sender has declared "-all" in SPF, then if the 
spammer forges the "From:", then anti-spam will use the fact 
that "From:" and envelope sender (or Return-Path:) are not 
the same, as another probabilistic measurement.

Well, I would argue that:

1) The IETF should not rely on a potentially unavailable feature of an
MTA


IETF can not rely on SPF or SenderID to be on every MTA either.

One inherently assumes that verifiers (receivers) will do what it best to 
prevent forgery, as one assumes that anti-forgery is desireable in the 
marketplace.



or perhaps non-existent anti-spam filter to prevent phishing.
Whatever anti-forgery system is ultimately put forth by MARID/IETF, it
should protect against both envelope and header forgery.


It is going to be impossible to do that with per-domain anti-forgery in the 
real world for most domains and senders, without applying some probability 
methods.

For example, if you follow the PRA, then all spammer has to do is insert a 
Resent-Header: matching his spam domain, but forge the From: header.  Even with 
SenderID, you have to apply some probability methods to know that case is a 
forgery.

SPF has similar issue.  Spammer can use unforged envelope, but forge the 
headers.  I see no difference.  Neither can give you a binary answer without 
giving false negatives.

I do see SenderID as an added complication which will add nothing in terms of 
new uncorrelated data.



This could be
as simple as making SPF the standard, and then re-writing the RFC-2822
FROM header, and Sender headers, to be the same address. 


If you change the requirements on e-mail such that headers no longer have the 
flexibility they have now, then yes maybe you can get something worked out that 
is binary (yes or no) answer.  But that simply isn't realistic.  You would have 
to change all the MTA and MUAs in the world.



2) Sender ID, for the most part, accomplishes both of these
authentications, since you are supposed to publish a classic SPFv1
record in addition to the SPFv2/pra record in order to comply with
Sender ID. So you get RFC-2821 and RFC-2822 protection.


I assert above, you actually get no extra protection.  Perhaps all you get is 
making it very difficult for anti-spam to do it's job, because anti-spam that 
competes with Microsoft or is GPL does not want to sign Microsoft's license.  
IMHO, with SenderId you may get more people publishing SPF records, but in the 
end you will get less diversity in the ways those records are enforced.  And to 
me, that is very dangerous, because we need a lot more innovation in anti-spam 
in future.



Bankers are a funny lot. In the U.S., banking is a heavily regulated
industry. Bankers are not interested in "probabilistic" half-measures
such as you describe,


If that is the case, someone better explain to banks that SenderID is not a 
binary result either.


they are interested in regulatory compliance and
repeatable, predictable results (be they financial or otherwise).


Probability methods can give repeatable results within the confidence interval 
chosen in the methods used.

Using SenderID (or SPF) with no probability analysis will give more false 
negatives, because all the spammer has to do is forge the From: header but not 
the Resent-Header.  How many people still do not understand this or do not 
agree?



As such, I think the banking industry will only seriously adopt an
anti-forging technology once it is on the official IETF standards track,


I think they wait for this because of the costs in implementing (as you 
astutely pointed out), wanting to know the solution is endorsed by the 
community experts, that most receivers will be using the data, and thus be able 
to test the result on a significant sample.

Thus Microsoft might have great influence in their confidence.