At 15:43 08/07/2009 Wednesday, Alessandro Vesely wrote:
alan wrote:
At 09:00 08/07/2009 Wednesday, Michael Deutschmann wrote:
V-SPF mostly gives inferior information. In V-SPF, softdeny is pointless,
and V-SPF neutral collapses together G-SPF neutral, softdeny and fail. But
V-SPF's fail maps to something that just doesn't exist in G-SPF.
i think this definition is pointless and misleading
+1, and adding a D-SPF is not going to clarify much.
what? as i keep saying there is no V-SPF G-SPF or D-SPF
just SPF
All spf domains can have -all {if and only if they control the outgoing
mail-flow entirely or know all the originating ip's that users will use}
if they do not they then use ? or ~ all
Vice-versa, an ESP may use -all to force their users to use SUBMIT.
yes their domain their policy, if users disagree use another provider, a good
one that allows per user spf and for the user to decide how their own mail is
used
all receivers MUST whitelist non-SRS forwarders that their users are using as
in either scheme {above} the ip of their users external forwarders will not
be passed by either SPF
{SRS forwarders exist just to enable forwarding to not
require whitelisting}
if any receiver dosn't whitelist forwarders and rejects on -all, they will
loose legit user mail {if and only if that user has a non-SRS forwarder}
thus a receiver choosing to not whitelist forwarders cannot use SPF to make
any determination about email, simple
I disagree with this view. The burden is on forwarders to work out how to do
their job. In order of increasing compliance and difficulty, they can
0) forward naively and be blocked,
1) forward with a blank MAIL FROM,
2) forward with static (or VERPed) senders if they really care,
3) deploy SRS, or
4) get whitelisted at the target host.
The last point implies an agreement, thereby complying also with privacy laws
that require an explicit consent to use someone else's email address. It is
more difficult because the software to automate it does not exist yet, AFAIK.
err forwarders and receivers are working for one person the user {they should
both be complying with their wishes}
the user should they choose to use a forwarder to get their address A to
forward to their address B
the reciever should have the option available to the user to whitelist mail
comming from addressA's servers to their addressB
{this option should be implemented by provider B or have a public policy
stating they won't accept forwards}
if the provider of addressB doesn't provide this option it is that policy that
is responsible for lost email not the forwarders
{the forwarder can choose to deply SRS to get around this policy, blank
MAIL-FROM is a bonehead idea frankly}
if the reciever of addreess B refuses forwards at that point the user should
choose another provider to receive their forwarded mail or choose not to
forward all address' to one pickup point
though i know as many of my own users have many forwards from many address'
pointing to their mailboxes here that telling them forwarding is bad would be a
dumb idea.
equally many choose to forward their mail here to their office/home/hotmail or
gmail
hotmail happily whitelists forwarders {via to: or cc: matching the
forwarded-address not ip as far as i can tell}
gmail provides external pop3 pickup so we advise users wanting to forward there
to utilize this instead
most office/home setups hapilly whitelist us at the users request, if they
don't we tell the user to not forward
its not rocket science
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: 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
Modify Your Subscription: 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