At 07:48 27/11/2009 Friday, Alessandro Vesely wrote:
alan wrote:
At 11:23 26/11/2009 Thursday, Ian Eiloart wrote:
Any "false positives" can squarely be blamed on the publisher of the
record or the forwarder of the email.
true, {as to the publisher}
the non-srs-forwarder is blameless though as well his-server his-rules as
far as how he checks incomming mail for validity and non-srs-forwarding
is done on behalf of the shared-user of both systems {ie user who has
account with non-srs-forwarder and the final reciever}
His server, his rules. Agreed. However, if he knowingly forwards mail with
broken SPF, then that's nobody else's fault.
{only if his server is capable of SRS few are} 90% of servers i see day to
day are just plain incapable M$ exchange being the most common
and few admins decide to feorward mails, this is usually the choice of the
end user {management with blackbery or road-warrior wanting to use
*webmail-provider*}
The decision that is up to users is to enable either forwarding by one server
or fetching by the other one. Gmail and many other servers offer fetching: it
is the solution with fewer problems.
true this is what we suggest for all gmail users {i should stop using gmail as
default webmail service in statements like above now ammended}
we even offer them a how-to for setting up gmail to pop/submit
so they can do both incoming/outgoing via gmail-interface without even altering
their SPF as both flows actually go via us
{its a pity more webmail systems don't offer the utility}
so in that case its a failure of the user to {select a non-srs-forwarder
with adequate inbound filtering} and to inform the end-recieving system
to not perform spf filtering on mail non-srs-forwarded to him from
non-srs-forwarders-ip
But many people don't "select" their forwarders. For example, our students
can opt to have their "sussex.ac.uk" email forwarded to a third party
account. They can't choose who does the forwarding, though!
well actually they could {if you didn't already do srs} they could get a
provider like ourselves to middle-man the mail {by setting yours to forward
to us}
so we make it SRS compliant and before it reaches the whitelisting incapable
end destination {like a lot of businesses with exchange have to}
However, the middle address will be visible in case the final server rejects a
message because the mailbox is full. That may be unacceptable in case the
first (vanity) address bears utter significance.
true but few business-related forwarders have the mailbox full scenario
but yes this would be an issue if it happened {but less of one than their
server returning DSN's to ever SPF utilising sender}
BTW, what you call "SRS compliant" should actually be called "SPF compliant".
SRS is not the only technique to change envelope senders and thus avoid
breaking SPF.
true my bad ;)
if user has no method of disabling spf-checking on mail to him from
non-srs-forwarders-ip then he should be selecting a different
end-reception supplier as the current one is ill equipped to accept
non-srs-forwards {and thus should either ban non-srs-forwarding or not
reject on spf-fail}
Perhaps they'd be well advised to. Unfortunately, most end users don't know
about SPF. And, they don't know that they don't know!
they shouldn't have to but you just {like us} have a big button allowing them
to whitlist the sender {in webmail} {only shown if the mail appeared to be
forwarded} that brings them to the whitlisting of forwarders section of the
api
{or in our case a link in our web based "your mail that was rejected log"
beside any rejected due to SPF fail
but the means are many, hotmail do it by encouraging users to give their
forwarding-here address and i suspect then probing them to see if they need
whitlisting or not
{i must play with this option for our own few users who arn't techies,
luckily very few atm}
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}
most of our users are geeks thats why they come to us when they want more
control for their spamfiltering.
most have been with us since the past when their api to altering their
rejection criteria was a phonecall to me, but it was still a better api than
elsewhere
-------------------------------------------
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