If there were a standard for expressing and communicating such
policies, it would allow any MUA to communicate policy with any
compliant MTA. Then far more people would have the benefit of
using such a system.
I'm willing to volunteer to help draft such a standard, in line
with Section 2.6 of the Consent Framework. Who wants to help?
If you're proposing to draft a protocol which allows individual
block and pass prefrences to be expressed and passed freely around the
network I'd be very interested.
As per my latest posting, my interest is primarily in the format to
express a consent policy. We will need people to work on a protocol
to exchange such policies (and consent tokens for them) as well.
For now I think we need to work on the format for expressing the
policy, otherwise such protocols will have nothing to exchange. But
unless the volume of posts becomes too big I expect we'll keep it
all on-list, so feel free to join in at whichever stage interests
you most.
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.
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.
I'd like server level "blanket" policy to be expressable, and varying
degrees of domain, sub-domain and user groups to also be specified,
such that a sender MTA can build up a set of rules imposed by various
*organisational* levels of the recipent's network admin.
So far most of the discussion I've seen has centered around the idea
that the "recipient is king", much of it has been about the
recipient's personal consent policy.
Of course from the MTA administrator's point of view, they need to
protect their network from massive abuse. And of course it is the
right of the organisation to block whatever traffic it chooses from
its own network. Some people might be against the idea of additional
filtering over and above the personal consent policy of the
recipient, although I can understand why such filtering may be
necessary in practice.
My "gut-feeling" is that the consent policy of an individual
recipient is distinct from the organisation's network abuse policy
although there is likely to be some overlap between what annoys an
admin and what bothers their end-users.
Some might say that administrative filtering is more within the
scope of a BCP rather than a standard. I'm not sure either way.
Then any sender will be able to impose the rules before transport, and
the recipient will be able to apply them after and still benefit from
any saving made by having some mail delivery never even attempted.
This is an interesting approach. It suggests the idea of two protocols
(or maybe one protocol used for two different purposes):
- for sending personal consent policy to the ISP's MTA
- for a sending MTA to query a remote MTA's policy details
The latter is likely to be the more controversial.
I have access to MTA software to experiment with, and a first hand
knowledge of the implementation of many existing mail RFC's.
Excellent, we need some people who are in a position to try out any
proposed solutions. It's early days yet but that's why we need to
move things forward. Once we get some standards drafted we can try
them out and then feed back the results into improving such standards.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg