I looked at new version or proposal briefly and will reread it in fully as
I plan to read fully all that is contained in the archive last month. But
the problem is more fundamental that new version can not possibly address.
I would go as far as to say that its theoreticly impossible for RMX to do
what it is supposed to do without breaking maillists and similar mail relay
services because of the very basis of design for these proposals.
RMX and other similar proposals are there to verify mail sender (that person
or machine sending email) is authorized to use particular domain in the from
address. But validation is done by ip of the connecting mail server and
that means you're substituting one-hop (server-server) verification where
you actually want end-end verification. If you go by mailpath A->B->C
where A is origin and B is intermediate server, then by the very design,
best RMX can do for destination C is verify conversation and something about
site "B" but not anything about site "A" which is the origin. The
proponents will all say that if everybody is doing it and if B validates
A and C validates B then its the same as that C validates A but that is
where problem lies we do not have persistency of trust on the mail path
so if C validates B, what we have is that "C verfied that B is using some
third-party domain and that it is claiming that it has verified C". The
word "claiming" is the problem here, we have substituted real verification
of mail origin (which is what we wanted) for verification that some domain
being supplied by connecting server is there - that is all! And we all
know that domains are pretty easy to get hold of for spammers and tracing
by domain is actually less valuable then tracing by ip!
There are several ways to get around the above problem. One is to have
clear way for C to verify that email passed through A, i.e. that sender
network is aware that some mail originated there (this is mail tracking
- I'll mention this again in details later and have already discussed this
before in my notes). Another way is to use crypto signatures to provide
necessary trust - that is either email itself is entirely signed (S/MIME,
PGP, etc) or possibly it includes some token that we know only orign server
could have included (i.e. token can be verified from dns) - this is hashcash
and similar proposals. In all cases we would need to have destination contact
some service at origin domain to verify something about the email (like
tracking data, crypto key or signature, CRL, etc) just like RMX proposal
does it (i.e. dns check), so this basic idea would be used no matter what!
On Fri, 9 May 2003, Hadmut Danisch wrote:
On Thu, May 08, 2003 at 10:06:02PM -0700, william(_at_)elan(_dot_)net wrote:
RMX, MAIL-FROM, DSDNSBL all fail for mailing lists and for forwarding no
matter if you compare it to "MAIL FROM" or to envelope "From" header
or both.
We have already discussed this issue on the mailing list several
weeks ago and came to the conclusion that it doesn't break mailing
lists. I have also addressed this issue in the second version of
my draft.
Would you mind to inform yourself before posting such claims?
Hadmut
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg