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.