The marid protocol should be set up so that the sender
writes a sender policy record which allows the receiver
under marid core to use this record to verify any one or
more of the data sets the receiver wants to check.
Let me explain.
Want to do an SMTP mail from check? Okay.
Want to do an EHELO check? Great
Want to do an SMTP sender from check? Sure
Want to do any combination of SMTP mail from, EHELO and
SMTP sender from checks? Fine.
Want to do any combination of SMTP mail from, EHELO, SMTP
Sender from and PRA checks. Hey, that's fine too.
(This is the AOL choice.)
PRA is moved to its own spot to give MS the option, feel
you need a defensive patent and royalty free license. Hey,
go for it.
It may be that checking using SPF and Submitter is
sufficient. It may be that using CSV suffices.
However, we should only say to receivers you must run
checks. Which checks you run is up to you.
In turn this lets the market decide which checks are
optimal and deliver the best results.
If a service provider like AOL feels the optimal solution
is to check everything, hey ... go for it.
As to a public-key cryptography solution relying on DNS, on
the sender side, one would need to:
* amend the marid protocol to add the requirement to
publish a public-key;
* amend core to allow receivers to choose to check the
public key.
I would suggest it is too early to dictate this to senders.
Let me repeat so there is no misunderstanding:
* The sender under marid protocol publishes a sender
policy.
To be acceptable, this sender policy must allow the
receiver to run any one or more of a series of tests based
on SMTP mail from, ehelo, SMTP sender from and PRA.
At some point in the future we will add a form of
public-key cryptographic test.
* The receiver under marid core can elect what 'data sets'
she wants to check using the sender policy published for
the domain under the marid protocol.
From the sender's perspective, he says to the receiver:
"Want to check SMTP mail from, ehelo, SMTP sender from, PRA
... go ahead. Its all there and everything is in order."
The receiver can say, for example thanks, but I only need
to check the ehelo using the CSV protocol. All the rest of
these checks are redundant.
I am satisfied the data set from ehelo, along with the use
of reputation and accreditation services and ultimately a
light weight version of public key cryptography will
suffice.
Marid core should not tell a receiver you must check
everything, only that you may check one or more of the
following:
SMTP mail from
The protocol for using SMTP mail from is found in SPF
(needs to be updated).
SMTP sender from
The protocol for using SMTP sender from is found in
Submitter?
EHELO
The protocol for using EHELO is found in CSV.
PRA
The protocol for using PRA is found in PRA.
(At some future point in time, a public key cryptography
solution or some other variant which we have yet to think
about.)
In this way, it allows proponents of particular solutions
to provide the receiving market with a choice. This market
can then decide which solution it wishes to use based on
what best suits the needs of the receiver.
Write the rules so you dictate what information senders
must provide.
Don't write the rules to dictate a solution for receivers.
Allow the rules to be flexible to let proponents fashion a
solution within the established framework which best suits
the needs of the specific receiver or class of receivers.
So, if AOL feels, we want to check everything, then it will
look for a solution provider which allows it to check
everything.
At the same time if XYZ says, we don't need all this backup
checking and will only check this particular data set using
this approach, then presuming there is a solution provider,
that's up to XYZ.
:-)
John
John Glube
Toronto, Canada
The FTC Calls For Sender Authentication
http://www.learnsteps4profit.com/dne.html
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.734 / Virus Database: 488 - Release Date: 04/08/2004