From: "Stuart D. Gathman" <stuart(_at_)bmsi(_dot_)com>
On Sat, 25 Jun 2005, Hector Santos wrote:
I see, so can we generalize it like so?
Benefits:
- Can address Social Engineering issues (i..e, phishing) at the MUA
by displaying the PRA
Concerns:
- Requires adaptation (change) by MUAs to display PRA
- Requires two SPF records (SPF1 and SPF2.0/PRA) ???
Is this last concern correct?
- Requires a distinct SPF2.0/PRA record (or a single multi-scope aware
record, e.g. op=pra) to be useful. Reusing SPF1 only records for PRA
is evil and will make phishing easier.
- Does not help MTAs efficiently filter abusive senders unless
SPF1 is checked first.
Ok, I see what you are trying to say I think, but I want I am trying to
hopefully get is a Pro/Con list that maybe is independent of SPF1.
Unless we are saying:
Benefits
- Works better in conjunction with SPF1
Concerns
- Less Effective when SPF1 is not used.
Correct?
I know that is awkward. MSs strategy makes it difficult to explain.
So we have a Concern:
- PRA is diffcult to implement.
PRA could still be useful against phishing without SPF1, and
that helps end users.
The problem with this is that is all subjective. I mean, if one is
going to implement PRA, then of course, the reason is because they
want to help address the issue. Why implement if it wont' help?
So we need to see what are the pros and cons and see what is
the effectiveness or efficiency of the protocol over all the considerations.
Thats the problem I have with it. I don't see it and if I did, I would of
implemented long ago. I don't by the PRA concept and the idea
that it can help the user. In fact, I think it can confuse him more.
However, MTA admins want to know who/what is sending spam,
so they can block it before it ever gets to the end user, and
in fact before they have to waste bandwidth and resources receiving
the forgery.
Exactly, thats my philosophy too and I think society is leaning in this
direction more and more too - stop it before it gets to the user. Thats
SMTP level security.
The SUBMITTER optimization only works for legitimate messages.
If its legitimate, but again, its a subjective concept.
I guess what I am trying to say - what is the "automated concept" where
there is a TRUE (pass) or FALSE (fail) condition. If this result is in the
middle, then you make NO decision.
So for example, if a client is using SUBMITTER for the transaction, there is
a presumption of a HIGHER LEVEL client - this is GOOD because it raises the
bar. It is not longer a LEGACY client. This means that you can now
perform extra assumptions and considerations and checks.
So by using SUBMITTER, you either have:
1) A BAD GUY
2) A GOOD GUY
and assert there is nothing in between and by that I mean, if its bad guy,
you won't know it until you make the subjective AI and Human investigation
of the Mail Body itself and that too is subjective because what you call
spam may not be spam to others.
So the how trick to this is to basically squeeze out the legacy systems out
of the picture. If we don't, we are back to square one where you don't
know one way or another.
And unfortunately, when it is all said and done, the easiest way for a
spammer to avoid your message rejection is to avoid using any of the new
stuff and compliant with the mininum set of 821 and 822 requirements.
I get 30,000 forgeries every day, and only a few dozen real messages.
Just like the world, that is why I like to emphasize a protection at x821
first.
So, if MS wasn't so focused on world domination, SenderID
could benefit end users (Microsofts primary monopoly) by making
phishing harder, while SPF1 benefits mail admins by providing a tool
to reliably filter by MAIL FROM rather than IP.
I agree with your theory, I just not sure of SenderID/PRA has any value
here. I don't think it does and I am not saying that because I hate
Microsoft or disagree with their world dominance and monopolistic behaviors,
but purely base on its technical merits. If I could see it work, I would
of added a long time ago. But it is not easy to see how it can work, it is
easy to see how it can spoofed, and one thing for sure, it requires extra
payload.
If you are implementing SenderID in an MTA, you want to eliminate
the MAIL FROM forgeries first using SPF1, since that is cheap, before
you do the Sender-ID check.
Right, so you say
Benefit:
- More effective when used with SPF1
Let me update the list :-)
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com