forgery. If organisations ensured that all email correspondence is
actually shown (in 2821 MAIL FROM and EHLO, and 2822 From) to come
from the organisation then this would help phishing detection both
before and after SFP or Sender-ID is introduced. While technical
measures are needed to fight email forgery, I think that some business
practices could also do with examination.
IMHO this is not necessary. All that is necessary is that the envelope from
should contain a matching "-all" SPF record, and those who declare "-all"
records must be sure spammers are not be able to use the same envelope from.
As I wrote before, astute anti-spam can take it from there using probability
analysis over large samples.
IMHO, the RPA is really irrelevant, except perhaps for forwarding scenarios,
but the whole per domain anti-forgery concept is weak in forwarding scenarios,
so SenderID would not really resolve that weakness in my view. I never saw
that MSFT was really proposing RPA as their final solution. Technically it is
clear to me that has to be a first salvo in something else coming and I think
the something else would be per user anti-forgery using cryptography combined
with "hashcash" for anti-spam. So I never viewed SenderID as having a
technical advantage over SPF classic, just saw it as an enabling monopoly for
MSFT's other anti-spam plans. That is just a personal opinion, not fact.