At 10:09 AM 8/14/2003, Andrew Akehurst wrote:
..........
> It seems to me that if we had a means by which a sending MTA could
> request such profile from the receiving MTA before sending it has the
> potential to drastically cut down spam.
This is an idea which has been discussed before on the list. Some
people objected on the grounds that a spammer using a compromised
MTA might scan people's personal consent policy to see how to
produce messages which will slip through the recipient's filters.
Other people might prefer the idea of partial disclosure: only
allowing certain MTAs to query the policy, or only allowing a subset
of the policy to be disclosed.
It's potentially a useful feature for reducing traffic but it may
be open to abuse by spammers, so it's a little controversial.
From the consent framework, section 2.1:
-------snip-----
Portions of the CONSENT POLICY may be communicated to the SENDER according
to the SCOPE of the policy either by the CONSENT EXPRESSION COMPONENT or
the POLICY ENFORCEMENT COMPONENT. When communicated by the CONSENT
EXPRESSION COMPONENT, the purpose is to let SENDERS know what kind of
CONSENT RULES they should follow in order for their email to be accepted.
Examples of this might be when an ISP publishes a set of email policies for
other domains which must be followed in order for the email to be received.
When communicated by the POLICY ENFORCEMENT COMPONENT, the purpose of the
communications will be to inform the SENDER of LACK OF CONSENT by the
RECEIVER and to request a CONSENT TOKEN (if applicable). AGENTS
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, all according
to the CONSENT POLICY SCOPE.
-------snip-----
> I'd like to see several layers to this, though they are all pretty much
> the same in operation but differentiated by scope.
>
> I'd like MUA's to be able to forward their policy to the incoming
> POP/IMAP server, this would then be available to be queried by delibery
> agents, and hence get into the SMTP network.
I must admit, I do like the idea of sending my policy to my ISP's
incoming mail server. At the very least this would allow them to
block spam on my behalf, saving me the need to download useless
messages which I'll only have to delete or locally filter anyway.
From Consent framework, ibid:
---snip----
A CONSENT POLICY of a specific RECEIVER does not merely reflect his
choices. It is also based on the capabilities and settings of the CONSENT
EXPRESSION COMPONENT used, the capabilities and settings of the POLICY
ENFORCEMENT COMPONENT used, and by the SCOPE of the CONSENT POLICY of
organization or ISP to which the RECEIVER belongs. The specific
implementation being used by the RECEIVER, or his organization/ISP might
support only specific types of CONSENT RULES which will be used in creation
of the policy. CONSENT POLICIES from multiple RECEIVERS 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 the RECEIVERS
within its domain. 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.
---snip----
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg