At 08:01 PM 7/3/2003 -0600, Selby Hatch wrote:
Yakov Shafranovich wrote:
....
In the consent model we have a SENDER and RECEIVER of email that
communicate with each other. The messages between the SENDER and the
RECEIVER are processed by MUAs and transferred by MTAs. The RECEIVER can
express his CONSENT POLICY to his MUA and MTA, which will enforce it for
incoming messages. This policy
References to this policy . . . (not the entire policy)
The whole policy cannot be shared with the sender since it will simply
allow the sender to guess what kind of messages can go through UNLESS the
policy relies on trusted third parties such as CAs for consent tokens.
may be communicated to the SENDER under
specific circumstances, usually after being triggered by an incoming
email message from the SENDER. This purpose of this communications will
be to inform the SENDER of lack of consent by the RECEIVER and to request
a CONSENT TOKEN (if applicable). A CONSENT TOKEN is a piece of data
exchanged between the RECEIVER and the SENDER, which will grant consent
to the SENDER in accordance with the CONSENT POLICY of the RECEIVER.
Examples of such tokens are C/R messages, hash cash tokens, e-postage,
digital certificates, trusted sender seals (such as Habeas and
BondedSender), etc.
Don't forget my simple keys.
A consent token is implementation specific - can be a key, certificate,
etc. We will keep this in mind.
Upon recipient
receipt
of a valid CONSENT TOKEN, the
RECEIVER will grant consent to the SENDER to a period of time defined by
the CONSENT POLICY.
I'm a little confuesed by the previous sentence. Do you mean that the
receiver will send a consent token to the sender and that from then
on, the receiver grant consent to the sender?
The receiver gets a consent token and grants consent to the sender.
Granting of consent may be accomplished by simply letting the email go
through, or may require sending back a token. This sentence simply means
that the receiver grants consent - whether a token is send back or not is
implementation specific.
A CONSENT POLICY of a specific end-user does not merely reflect his
choices. It is also based on the CONSENT POLICY of the software being
used, the organization to which the end user belongs, and the ISP. The
software being used, specifically the MUA and the MTA, might support only
specific types of consent rules which will be used in creation of the
policy. CONSENT POLICIES from multiple users maybe combined to create a
combined CONSENT POLICY for the entire organization or ISP. The
organization or ISP may also impose its CONSENT POLICY on its users and
subscribers.
For individually owned mail boxes, the consent policy should be unique
and specific to the mailbox owner.
However it may be based or combined with policies of the ISP.
MTAs when communicating with each other may share CONSENT POLICIES to
facilitate communications. They may also pass CONSENT TOKENS between
themselves in order to dynamically grant or revoke consent to the
RECEIVER. Multiple ISPs and organizations may also shared CONSENT
POLICIES in order to allow for interoperability between themselves.
Standard CONSENT POLICIES may also be defined as Best Current Practices
(BCP) documents.
Based on this, the actual consent tokens must not be part of the
consent policy, otherwise these would also be shared between MTAs.
This seems like a way of compromising consent tokens.
Some tokens can be shared - like public certificates.
.....
5.2. Policy Enforcement Component.
This category includes portions of the MTAs/MUAs that enforce the CONSENT
POLICY defined for the end user as modified by the organization and the
ISP's CONSENT POLICIES. These tools are used while the SMTP transaction
takes place. Today there is no one comprehensive type of tool to do that,
instead combinations of tools are used. Examples of these tools include:
Challenge/Response Systems
Reverse DNS checks (RMX/rDNS/etc.)
Lookups in Realtime Black Lists (RBLs)
Verification of digital certificates with a CA
Checking for trusted sender seals (Habeas, etc.)
Filtering (SpamAssasin, etc.
Lookups in known spam databases (SpamNet., DCC, etc.)
Blacklisting
Greylisting
Virus scanning
Am I correct in my understanding that the above tools represent
today's tools and not proposed tools? Do you have a section
for listing proposed tools?
Yes, this is listing today's tools. These three sections will list today's
tools and proposals.
...
Great start. Could you use any assistance?
Definitely. There has been a lot of discussion much of which very relevant
to this document. I might have missed things, so I definatly would
appreciated a review of the document and any suggestions on style, order,
spelling, content, anything!
Yakov
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg