At 15:14 28/11/2009 Saturday, Alessandro Vesely wrote:
alan wrote:
At 07:48 27/11/2009 Friday, Alessandro Vesely wrote:
I cannot understand this. Webmail servers only have the chance to determine
that a message appears to be forwarded, and hence present the big button,
_after_ they have already accepted the message. What do they do if the user
does _not_ whitelist the sender at that stage?
yes this only happens on the 90% of non SPF using mail that gets through {but
appears non-srs-forwarded}
the link is presented beside the rejected mail {due to SPF failure} in their
web based view of the rejected mail log
{we provide a rejected mail log to the user so they can tweak which
DNSBL's,HELO-checks,PTR-checks,manual whitelists/blacklists etc are
working/not-working for them, and ammend their filtering config appropriatly}
we have found it works well with over time the user turning on more and more
aggressive checks and whitelisting senders when needed, {often pruning their
whitelists after convincing sender to stop doing whatever dumb thing caused
the test to fail, like helo-as blah.blah.local}
Ah, now I got it. It seems clever enough to me, even if users have to miss the
very first messages --probably tests in most cases.
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
as the system as-is is hoped to be adopted by providers or admins wanting to
stick a filter in front of exchange/in-house-system
{as its designed to be a front-end only and validates attempted address' by
calling forward to backend mailbox server {split-dns so it only sees the mx for
backend server}
thus if a users address isn't previously defined it uses the per domain defaults
{and thus the postmaster only has to add users/address' to the filtering api
when exceptions to the defaults are needed}
One added benefit is that users have a means to maintain a list of their
whitelistings, subscriptions, etcetera.
-------------------------------------------
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
-------------------------------------------
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