alan wrote:
I agree with Ian that it would be nice to have something like this as a
standard. That might provide for the sender setting up any relevant detail, and
(non-geek) users just having to agree, either manually or automatically.
However, the obvious advantage of your approach is that it requires minimal or
no compliance from senders.
as far as standards yup hopefully in the end {whenever that is} the websites
api will be documented well enough and structured in a way
that 3rd party plugins could talk direct to it so all the user has to give the
plugin is the base url of the admin site and their admin id/password
and then thus plugin could present whatever options it wished from the mail
client
{and similarly webmail clients could be tweaked to present their own api to the
filtering}
but currently even the filtering site api dosn't present all available options
to the user, many still require calling me and having me alter their preferences
It probably makes sense to standardize those filtering options that
are based on envelope data. It is easier, because there are not many
of those. For the content, I'd only bother a few relevant header
fields, e.g. Authentication-Results, X-Spam-Status, X-Spam-Level,
SPF-Received, if at all. It is not practical to require expansive
filtering.
Obviously, any mail site may add whatever (optional) filtering
rules. The purpose of _requiring_ some of them is in case a message
is forwarded multiple times. Consider this scenario:
sender-> user(_at_)site -> alias(_at_)intermediate -> other(_at_)final
In such cases, the rules at the final site must not be stricter than
those at the intermediate one. Thus, there should be no need to
fine-tune downstream sites. It would then be sufficient to configure
whitelistings at one site only, as standardized settings can easily
be exchanged between compliant sites, if the given standardization
provides a way for doing that.
One added benefit is that users have a means to maintain a list of their
whitelistings, subscriptions, etcetera.
In the above scenario, subscriptions might be retrieved recursively
and result in a single web page.
-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/
[http://www.listbox.com/member/]
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com