Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: SPF: Discuss

Senderside forwarder-problem mitigation

  

 
First page Previous page 1 2 Next page Last page  View All SPF discuss RSS feed   Index | Next | Previous | View Threaded


michael at talamasca

Jul 3, 2009, 9:05 PM

Post #1 of 35 (3518 views)
Permalink
Senderside forwarder-problem mitigation
I like SPF, however, I've always had a problem with the arrogant
attitude some show towards the forwarding problem -- that receiverside
implentors should ignore it to force forwarders to change. (I instead
think receivers should only deploy SPF on each mailbox once it is
confirmed that all forwarders are whitelisted.)

I find this harmful because it defeats the goal of widespread senderside
SPF deployment using "-all". Senders who, according to the intention of
the standard, qualify for "-all" will instead use "~all" or "?all"
merely to make sure their mail gets through even if they send to a user
behind a non-SRS forwarder.

This destroys valuable information -- since sometimes a site can be
"?all" for legitimate reasons, and sometimes just to dodge the forwarder
problem. Receivers who have no incoming forwards or have whitelisted
them all would really like to know the difference.

One way to avert this problem is to change the SPF deployment strategy,
as I have been calling for since I joined the list. That's not working
too well, though.


However, I have another idea: extend SPF to allow senders to signal
their intentions with respect to the forwarder problem, by adding a
"Forwarder Mitigation" option.

"fm=soft" would indicate the sender cares more about avoiding the
forwarder problem than it does about preventing forgery to users who
have not told their ISP about their forwards. It would effectively
disable SPF, but could be overridden by users who have whitelisted their
forwarders.

"fm=hard" would do the opposite, instructing the receiver to show no
mercy to possible forwards. Sites that are presently skittish about
arming SPF at the receiverside, might turn it on just for senders
carrying this flag in their record.

With these options, senders would then be free to use "-all" in all
cases where it is appropriate by the original intention of the standard.


Other "fm=" options could be used to indicate special approaches to the
forwarding problem. In particular, we could define a "fm=dkim" option
to indicate that the sender always adds a DKIM signature for the
return-path domain. DKIM isn't usually broken by forwards.

(This would also be good politics, showing that we are above the Not
Invented Here syndrome...)

A receiver that believes it has whitelisted all forwarders would be free
to ignore fm=dkim and block incoming SPF-fail e-mails at RCPT, as
before. (Which means it would be a very bad idea for a sender who
dislikes IP-based authentication to try "v=spf1 fm=dkim -all".)

But a receiver worried about the forwarding problem can let SPF-fail
e-mails past RCPT, while setting a flag that will cause rejection at
DATA if the expected signature is bad or absent.

This indication would be orthogonal to DKIM's own
SSP/ADSP/whatever-they-finally-call-it record. ADSP asserts that a
signature for the domain of the From: is required, while SPF fm=dkim
would assert that a signature for the domain of the MAIL FROM: is
required. If they are different, then in DKIM's vocabulary the
signature demanded by fm=dkim would be "third-party".

---- Michael Deutschmann <michael [at] talamasca>


-------------------------------------------
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


stuart at bmsi

Jul 4, 2009, 5:47 AM

Post #2 of 35 (3434 views)
Permalink
Re: Senderside forwarder-problem mitigation [In reply to]
On Fri, 3 Jul 2009, Michael Deutschmann wrote:

> I like SPF, however, I've always had a problem with the arrogant
> attitude some show towards the forwarding problem -- that receiverside
> implentors should ignore it to force forwarders to change. (I instead
> think receivers should only deploy SPF on each mailbox once it is
> confirmed that all forwarders are whitelisted.)

You are correct. The forwarding problem is strictly a receiver
issue. Only the receiver can know who their forwarders are, since
they "hired" them. SRS is never necessary when a receiver is on the
ball. (In real life, receivers set up forwards willy nilly with no
record or memory of what they have done.) You will find your recommendation
in Best Practices on openspf.org.

Asking a forwarder to implement SRS is strictly a convenience for
a lazy receiver. However, this is not as arrogant as you imply,
since the forwarder "works" for the receiver.

You are *absolutely* correct that the lazy receiver ("forwarding") problem is
never an excuse for a sender to not use "-all". Things like emails
sent by 3rd parties like web sites could be such an excuse for the sender,
but the "Web Generated" instructions in openspf.org will eliminate
the problem when properly implemented by the 3rd party sender.

--
Stuart D. Gathman <stuart [at] bmsi>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


-------------------------------------------
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


michael at talamasca

Jul 4, 2009, 9:33 PM

Post #3 of 35 (3441 views)
Permalink
Re: Senderside forwarder-problem mitigation [In reply to]
On Sat, 4 Jul 2009, Stuart D. Gathman wrote:
> You are *absolutely* correct that the lazy receiver ("forwarding")
> problem is never an excuse for a sender to not use "-all".

That's all well, but we have no means to force the senders to behave. If
the sender decides the pain of having outgoing mail blocked due to an
unhandled forwarding problem (which is concentrated on the sender
himself), is a bigger risk than the pain of having forgeries get delivered
to SPF-protected mailboxes (which mainly annoys strangers), we can't stop
him from using ?all. The best we can do is provide a safer channel for
this desire.

Even if all forwarders did behave, fm= would provide a great improvement
by allowing SPF to be partially enabled in the presence of
unknown-to-the-ISP traditional forwarders. "fm=hard" allows the sender to
volunteer to take the forwarding-problem risk, and "fm=dkim" would nullify
the forwarding problem if implemented at both ends.

---- Michael Deutschmann <michael [at] talamasca>


-------------------------------------------
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


vesely at tana

Jul 5, 2009, 3:05 AM

Post #4 of 35 (3433 views)
Permalink
Re: Senderside forwarder-problem mitigation [In reply to]
Michael Deutschmann wrote:
> With [fm=] options, senders would then be free to use "-all" in all
> cases where it is appropriate by the original intention of the standard.

The original intention of the standard is to compute whether a
server is authorized to use the domain name in the sender's address.
during SMTP transactions. Since forwarding is part of that, it is
included in that intention. IOW: I think it's very difficult to
specify when a message is being "forwarded"; therefore it is
difficult to tell the difference between "fm=soft -all", and, say,
"fm=hard ~all".


> A receiver that believes it has whitelisted all forwarders [...]

For the same reasons as above, such belief is necessarily heuristic.
Forwarders generally don't declare their existence before using an
email address (as they should, according to privacy norms that
require explicit consensus for such use.) When they send, there is
no way to automatically distinguish them from other transmitters
that don't pass SPF checks for their own reasons.


-------------------------------------------
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


michael at talamasca

Jul 5, 2009, 4:49 AM

Post #5 of 35 (3432 views)
Permalink
Re: Senderside forwarder-problem mitigation [In reply to]
On Sun, 5 Jul 2009, Alessandro Vesely wrote:
> Michael Deutschmann wrote:
> > With [fm=] options, senders would then be free to use "-all" in all
> > cases where it is appropriate by the original intention of the standard.
>
> The original intention of the standard is to compute whether a
> server is authorized to use the domain name in the sender's address.
> during SMTP transactions. Since forwarding is part of that, it is
> included in that intention. IOW: I think it's very difficult to
> specify when a message is being "forwarded"; therefore it is
> difficult to tell the difference between "fm=soft -all", and, say,
> "fm=hard ~all".

"fm=soft -all" = vanity domain where the owner is completely confident that
all legitimate outgoing mail will actually pass through the listed servers.
But he can't be sure that no mailbox he attempts to send to will relay the
message elsewhere, so he cautions ISPs that a legitimate message might be
further relayed after it leaves the authorized server.

"fm=hard ~all" = not a useful configuration. The advantage of "fm=hard" for
the sender is improved backscatter reduction, which is defeated by lack of
-all.

The two are similar in receiverside behavior when the receiver has poor
knowledge of incoming forwards -- although I would consider "fm=soft -all"
in this case to be more similar to "fm=hard ?all".

But the difference is that when incoming forwards are known, "fm=soft
-all" becomes instead equivalent to "fm=hard -all", while "fm=hard ~all"
doesn't change. Except, of course, that SPF is ignored when the forwarder
whitelist matches.

> > A receiver that believes it has whitelisted all forwarders [...]
>
> For the same reasons as above, such belief is necessarily heuristic.
It's heuristic at most ISPs, which don't communicate with their users about
such things.

But an ISP with a per-mailbox anti-spam control panel can obtain accurate
information for the subset of mailboxes owned by users capable of using
it. Vanity domains are often similar.

The main point of the proposal is that this elite set of users is being
robbed of chances to definitively deny certain forged e-mails, under the
status quo.

---- Michael Deutschmann <michael [at] talamasca>


-------------------------------------------
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


stuart at bmsi

Jul 5, 2009, 5:55 AM

Post #6 of 35 (3437 views)
Permalink
Re: Senderside forwarder-problem mitigation [In reply to]
On Sun, 5 Jul 2009, Michael Deutschmann wrote:

> On Sun, 5 Jul 2009, Alessandro Vesely wrote:
> > Michael Deutschmann wrote:
> > > With [fm=] options, senders would then be free to use "-all" in all
> > > cases where it is appropriate by the original intention of the standard.
> >
> > The original intention of the standard is to compute whether a
> > server is authorized to use the domain name in the sender's address.
> > during SMTP transactions. Since forwarding is part of that, it is
> > included in that intention. IOW: I think it's very difficult to

Receiver forwarding is *not* part of the sender policy and can never be
because it is set up by the receiver, not the sender. It is part
of the receiver policy. It is trivial to handle if the receiver
can remember what forwarders they have contracted. If they can't
(the usual case), then they simply can't reject on SPF FAIL. But
this is not something the sender can or should worry about when
setting a *sender* policy.


-------------------------------------------
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


michael at talamasca

Jul 6, 2009, 1:10 AM

Post #7 of 35 (3434 views)
Permalink
Re: Senderside forwarder-problem mitigation [In reply to]
On Sun, 5 Jul 2009, Stuart D. Gathman wrote:
> But [forwarding] is not something the sender can or should worry about
> when setting a *sender* policy.

The sender can still offer an opinion about how the receiver should
balance the risks.

Some senders don't see any point in taking risks with their deliverability,
however minor, just to help strangers detect forgeries.

But others may see SPF as valuable only as a backscatter preventer, and
presently not very effective because sane ISPs will not turn SPF on globally.
They would love to use "fm=hard" to tell a receiver "go ahead and ignore the
forwarder problem; I accept responsibility for the FP risk.".


Also, don't forget the potential for fm values other than hard or soft,
which can advise the receiver of alternative ways to recognize legitimate
forwarded messages. I already suggested "fm=dkim" in the original thread.

Another possibility is "fm=callback", which would be used by senders using a
SES/BATV type scheme. This would explicitly invite the receiving server to
do callback verification in the event of a non-PASS SPF result. While that
would be a much clunkier protocol than DKIM, it could be implemented much
faster.

SES/BATV proponents have long pointed out that their proposals would
terminate forgeries if everyone did callback. But everyone will not use
callback, since some of us consider it abusive. And some systems will give
misleading results and/or cause auto-blacklisting. But "fm=callback" would
resolve this by indicating informed consent and promising that callback will
give useful information.

A streamlined version of the above would be to have an "fm=unneeded",
option, which would indicate that a false SPF Fail result is simply
impossible, due to an exists mechanism which queries SES/BATV validity via a
custom DNS server. This would be even harder to implement on the sender end
than DKIM, but would be downwards compatible to receivers ignorant of fm=.

---- Michael Deutschmann <michael [at] talamasca>


-------------------------------------------
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


stuart at bmsi

Jul 6, 2009, 3:22 PM

Post #8 of 35 (3437 views)
Permalink
Re: Senderside forwarder-problem mitigation [In reply to]
On Mon, 6 Jul 2009, Michael Deutschmann wrote:

> On Sun, 5 Jul 2009, Stuart D. Gathman wrote:
> > But [forwarding] is not something the sender can or should worry about
> > when setting a *sender* policy.
>
> The sender can still offer an opinion about how the receiver should
> balance the risks.
>
> Some senders don't see any point in taking risks with their deliverability,
> however minor, just to help strangers detect forgeries.

At this point, not having a useful SPF record is a deliverability risk.

> But others may see SPF as valuable only as a backscatter preventer, and
> presently not very effective because sane ISPs will not turn SPF on globally.

There is *zero* risk to SPF when correctly implemented. Large (as opposed to
"sane") email providers (as opposed to ISPs) are often technically unable
to correctly implement SPF for received mail due to not having a way to track
forwarders contracted by their users. The correct (nut just sane)
thing to do in that case is not to reject on SPF. They are technically unable
to "turn on" SPF in the first place without some kind of infrastructure to
support tracking all the "informal MXes" (receiver forwarders).

SRS lets the forwarders do the job (of simplifying informal MX support for
receivers), but why would they want to? It can also be done by the receiving
email provider (e.g. web page for users to register their forwarders and opt-in
to SPF).

> They would love to use "fm=hard" to tell a receiver "go ahead and ignore the
> forwarder problem; I accept responsibility for the FP risk.".

There is zero FP "method" risk to SPF. There is only a "user" risk of
braindead (incorrectly implemented) receivers (or mistakes in the SPF record by
the sender). The "forwarding problem" is simply an incorrectly implemented
receiver. Adding yet another useless layer to SPF for receivers to get right
is not going to improve the odds of receivers getting it right.

As to why "I really mean it" layers are useless, consider this:
http://gathman.org/papers/intense.html

For all the email I manage, there have been literally *zero* FPs due to SPF.
Most of our problems are with large providers that ignore a correct HELO
and reject DSL IPs even when not dynamic.

> Also, don't forget the potential for fm values other than hard or soft,
> which can advise the receiver of alternative ways to recognize legitimate
> forwarded messages. I already suggested "fm=dkim" in the original thread.

Notifying of other authentication protocols is useful, but is already
addressed in other modifier proposals.

--
Stuart D. Gathman <stuart [at] bmsi>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


-------------------------------------------
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


scott at kitterman

Jul 7, 2009, 9:39 AM

Post #9 of 35 (3430 views)
Permalink
Re: Senderside forwarder-problem mitigation [In reply to]
On Mon, 6 Jul 2009 01:10:01 -0700 (PDT) Michael Deutschmann
<michael [at] talamasca> wrote:
>On Sun, 5 Jul 2009, Stuart D. Gathman wrote:
>> But [forwarding] is not something the sender can or should worry about
>> when setting a *sender* policy.
>
>The sender can still offer an opinion about how the receiver should
>balance the risks.

I'm interested in some evidence that receivers are interested in this.
I've explored similar ideas with mail providers and anti-spam vendors in my
consulting work and gotten no traction.

>Some senders don't see any point in taking risks with their deliverability,
>however minor, just to help strangers detect forgeries.

I don't see a new modifier changing this.

>But others may see SPF as valuable only as a backscatter preventer, and
>presently not very effective because sane ISPs will not turn SPF on
globally.
>They would love to use "fm=hard" to tell a receiver "go ahead and ignore
the
>forwarder problem; I accept responsibility for the FP risk.".

This is what the current -all means (to a very close approximation). Why
would receivers believe this if they don't believe -all.

For backscatter prevention all that is needed for most domains is
sufficient deployment to deter spammers from using that domain. In general
we seem to have that now (there are some spammers that aren't deterred, but
most seem to be).
>
>Also, don't forget the potential for fm values other than hard or soft,
>which can advise the receiver of alternative ways to recognize legitimate
>forwarded messages. I already suggested "fm=dkim" in the original thread.

This pretty well removes the bandwidth/processing advantages of SMTP time rejection as you have
to receive the entire message to find out if it has a valid signature (this has been proposed
before).

>Another possibility is "fm=callback", which would be used by senders using a
>SES/BATV type scheme. This would explicitly invite the receiving server to
>do callback verification in the event of a non-PASS SPF result. While that
>would be a much clunkier protocol than DKIM, it could be implemented much
>faster.
>
>SES/BATV proponents have long pointed out that their proposals would
>terminate forgeries if everyone did callback. But everyone will not use
>callback, since some of us consider it abusive. And some systems will give
>misleading results and/or cause auto-blacklisting. But "fm=callback" would
>resolve this by indicating informed consent and promising that callback
will
>give useful information.

You can embedd batv/ses checks in your SPF record with exists and no
protocol extensions are required.

>A streamlined version of the above would be to have an "fm=unneeded",
>option, which would indicate that a false SPF Fail result is simply
>impossible, due to an exists mechanism which queries SES/BATV validity via
a
>custom DNS server. This would be even harder to implement on the sender
end
>than DKIM, but would be downwards compatible to receivers ignorant of fm=.
>

There has been some discussion of treating "v=spf1 -all" records
differently because there's no risk of false positive. Beyond that, I
don't think a false positive is impossible (it's not actually impossible
for "v=spf1 -all" records either).

Scott K


-------------------------------------------
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


spfdiscuss at alandoherty

Jul 7, 2009, 12:08 PM

Post #10 of 35 (3433 views)
Permalink
Re: Senderside forwarder-problem mitigation [In reply to]
At 17:39 07/07/2009 Tuesday, Scott Kitterman wrote:
>On Mon, 6 Jul 2009 01:10:01 -0700 (PDT) Michael Deutschmann
><michael [at] talamasca> wrote:
>
>
>There has been some discussion of treating "v=spf1 -all" records
>differently because there's no risk of false positive. Beyond that, I
>don't think a false positive is impossible (it's not actually impossible
>for "v=spf1 -all" records either).
>
>Scott K

thats the one i would like to see as i regularly see attempted back scatter to {random}@alandoherty.net

when my spf for any non-envelope-sender [at] alandoherty is "v=spf1 -all"

but too few reject on a hardfail

{by non-envelope-sender i mean any existing in outgoing including my many incoming only like abuse@ etc

what i'd love is either spf clients to treat "v=spf1 -all" as an absolute fail
or for us to have a "v=spf1 {something else}all" that meant absolute fail
{for valid use only in records where there is never any mail or helo with that domain}
or for records using redirects to serve separate records for valid/invalid address'
{any other preceding spf other than exp= or redirect= being a syntax error, "PermError"}

for receivers that aren't confident rejecting on -all
{as they don't want to break forwarders they don't know their users are using}
so they can reject these clear forgeries as they are invalid regardless of client ip



-------------------------------------------
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


michael at talamasca

Jul 8, 2009, 1:00 AM

Post #11 of 35 (3441 views)
Permalink
Re: Senderside forwarder-problem mitigation [In reply to]
On Tue, 7 Jul 2009, Scott Kitterman wrote:
> On Mon, 6 Jul 2009 01:10:01 -0700 (PDT) Michael Deutschmann
> >But others may see SPF as valuable only as a backscatter preventer, and
> >presently not very effective because sane ISPs will not turn SPF on
> globally.
> >They would love to use "fm=hard" to tell a receiver "go ahead and ignore
> the
> >forwarder problem; I accept responsibility for the FP risk.".
>
> This is what the current -all means (to a very close approximation). Why
> would receivers believe this if they don't believe -all.

The problem is that there are basically two different versions of SPFv1,
which use identical syntax but have different semantics. (SenderID produced
another pair, but that's a whole other story....)

In Gathman-SPF, SPF is applied by default after a forwarder whitelist has
exempted part of the mailstream. No forwarder whitelist means no rejecting
solely due to SPF fail. In this protocol, almost everyone can use -all
senderside, but it is foolish for an mail admin who doesn't know his users
well (such as in large ISPs) to deploy receiverside SPF checking that does
more than header tagging.

In Vessely-SPF, SPF is to be applied literally, with SPF fail being binding.
In this protocol, only two groups are entitled to actually use -all
senderside: SES/BATV users with a magic DNS server referenced in exists, and
people who are desperate enough to stop backscatter that they will willingly
risk rejected forwards. But receiver admins are assured that they can and
should arm reject-on-fail for users they don't know much about.

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.

---- Michael Deutschmann <michael [at] talamasca>


-------------------------------------------
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


scott at kitterman

Jul 8, 2009, 5:35 AM

Post #12 of 35 (3422 views)
Permalink
Re: Senderside forwarder-problem mitigation [In reply to]
On Wed, 8 Jul 2009 01:00:14 -0700 (PDT) Michael Deutschmann
<michael [at] talamasca> wrote:
>On Tue, 7 Jul 2009, Scott Kitterman wrote:
>> On Mon, 6 Jul 2009 01:10:01 -0700 (PDT) Michael Deutschmann
>> >But others may see SPF as valuable only as a backscatter preventer, and
>> >presently not very effective because sane ISPs will not turn SPF on
>> globally.
>> >They would love to use "fm=hard" to tell a receiver "go ahead and ignore
>> the
>> >forwarder problem; I accept responsibility for the FP risk.".
>>
>> This is what the current -all means (to a very close approximation). Why
>> would receivers believe this if they don't believe -all.
>
>The problem is that there are basically two different versions of SPFv1,
>which use identical syntax but have different semantics. (SenderID
produced
>another pair, but that's a whole other story....)
>
>In Gathman-SPF, SPF is applied by default after a forwarder whitelist has
>exempted part of the mailstream. No forwarder whitelist means no rejecting
>solely due to SPF fail. In this protocol, almost everyone can use -all
>senderside, but it is foolish for an mail admin who doesn't know his users
>well (such as in large ISPs) to deploy receiverside SPF checking that does
>more than header tagging.
>
>In Vessely-SPF, SPF is to be applied literally, with SPF fail being
binding.
>In this protocol, only two groups are entitled to actually use -all
>senderside: SES/BATV users with a magic DNS server referenced in exists,
and
>people who are desperate enough to stop backscatter that they will
willingly
>risk rejected forwards. But receiver admins are assured that they can and
>should arm reject-on-fail for users they don't know much about.
>
>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.

The differences are under the control of the receiver, so there is really
nothing to specify on the sender side.

Scott K


-------------------------------------------
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


dotzero at gmail

Jul 8, 2009, 5:42 AM

Post #13 of 35 (3431 views)
Permalink
Re: Senderside forwarder-problem mitigation [In reply to]
On Wed, Jul 8, 2009 at 8:35 AM, Scott Kitterman<scott [at] kitterman> wrote:
> On Wed, 8 Jul 2009 01:00:14 -0700 (PDT) Michael Deutschmann
> <michael [at] talamasca> wrote:
>>On Tue, 7 Jul 2009, Scott Kitterman wrote:
>>> On Mon, 6 Jul 2009 01:10:01 -0700 (PDT) Michael Deutschmann
>>> >But others may see SPF as valuable only as a backscatter preventer, and
>>> >presently not very effective because sane ISPs will not turn SPF on
>>> globally.
>>> >They would love to use "fm=hard" to tell a receiver "go ahead and ignore
>>> the
>>> >forwarder problem; I accept responsibility for the FP risk.".
>>>
>>> This is what the current -all means (to a very close approximation).  Why
>>> would receivers believe this if they don't believe -all.
>>
>>The problem is that there are basically two different versions of SPFv1,
>>which use identical syntax but have different semantics.  (SenderID
> produced
>>another pair, but that's a whole other story....)
>>
>>In Gathman-SPF, SPF is applied by default after a forwarder whitelist has
>>exempted part of the mailstream.  No forwarder whitelist means no rejecting
>>solely due to SPF fail.  In this protocol, almost everyone can use -all
>>senderside, but it is foolish for an mail admin who doesn't know his users
>>well (such as in large ISPs) to deploy receiverside SPF checking that does
>>more than header tagging.
>>
>>In Vessely-SPF, SPF is to be applied literally, with SPF fail being
> binding.
>>In this protocol, only two groups are entitled to actually use -all
>>senderside: SES/BATV users with a magic DNS server referenced in exists,
> and
>>people who are desperate enough to stop backscatter that they will
> willingly
>>risk rejected forwards.  But receiver admins are assured that they can and
>>should arm reject-on-fail for users they don't know much about.
>>
>>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.
>
> The differences are under the control of the receiver, so there is really
> nothing to specify on the sender side.
>
> Scott K
>
>

+1

I'm more focused on the use of SPF (plus DKIM signing) in the context
of phishing.

General rant (not directed at Scott):

As a sender, if I publish a record that ends in -all and you, the
receiver choose to pass mail claiming to be from one of my domains
(that fails) to one of your endusers, I am going to point them in your
direction when they contact me about that phishing email. I can't
force you to any given behavior (King Canute invocation) but I can
make sure that your endusers know that I have taken steps to provide
you with clear information as to which IP addresses are authorized to
send mail for particular domains.


-------------------------------------------
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


michael at talamasca

Jul 8, 2009, 6:16 AM

Post #14 of 35 (3427 views)
Permalink
Re: Senderside forwarder-problem mitigation [In reply to]
On Wed, 8 Jul 2009, Scott Kitterman 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.
>
> The differences are under the control of the receiver, so there is really
> nothing to specify on the sender side.

Yes there is. If the two sides are not coordinated, breakage results.

If the receiver speaks V-SPF and the sender speaks G-SPF, the forwarding
problem bites.

If the receiver speaks G-SPF and the sender speaks V-SPF, SPF becomes
ineffective as a forgery blocker because almost no V-SPF senders use -all.

In both cases SPF would be more effective if the receiver knew what form
the sender was speaking. "fm=soft" will clarify that G-SPF was intended,
while "fm=hard" provides access to the stricter fail of V-SPF.


I suspect the original intention of SPF was to have senders write as if
for G-SPF, and for receivers to treat polices as if they were V-SPF, thus
creating a pincer that would crush the forwarders into submission. But
this backfired completely. Now receivers use G-SPF and many senders use
V-SPF.

Note: I consider a false positive mail rejection to hurt the sender more
than the receiver. Thus, it does not appear to be a significant problem
that receivers might deliberately ignore "fm=hard". The real problem is
senders who are afraid to use G-SPF because of V-SPF receivers.

---- Michael Deutschmann <michael [at] talamasca>


-------------------------------------------
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


spfdiscuss at alandoherty

Jul 8, 2009, 6:41 AM

Post #15 of 35 (3436 views)
Permalink
Re: Senderside forwarder-problem mitigation [In reply to]
At 09:00 08/07/2009 Wednesday, Michael Deutschmann wrote:
>On Tue, 7 Jul 2009, Scott Kitterman wrote:
>> On Mon, 6 Jul 2009 01:10:01 -0700 (PDT) Michael Deutschmann
>> >But others may see SPF as valuable only as a backscatter preventer, and
>> >presently not very effective because sane ISPs will not turn SPF on
>> globally.
>> >They would love to use "fm=hard" to tell a receiver "go ahead and ignore
>> the
>> >forwarder problem; I accept responsibility for the FP risk.".
>>
>> This is what the current -all means (to a very close approximation). Why
>> would receivers believe this if they don't believe -all.
>
>The problem is that there are basically two different versions of SPFv1,
>which use identical syntax but have different semantics. (SenderID produced
>another pair, but that's a whole other story....)
>
>In Gathman-SPF, SPF is applied by default after a forwarder whitelist has
>exempted part of the mailstream. No forwarder whitelist means no rejecting
>solely due to SPF fail. In this protocol, almost everyone can use -all
>senderside, but it is foolish for an mail admin who doesn't know his users
>well (such as in large ISPs) to deploy receiverside SPF checking that does
>more than header tagging.
>
>In Vessely-SPF, SPF is to be applied literally, with SPF fail being binding.
>In this protocol, only two groups are entitled to actually use -all
>senderside: SES/BATV users with a magic DNS server referenced in exists, and
>people who are desperate enough to stop backscatter that they will willingly
>risk rejected forwards. But receiver admins are assured that they can and
>should arm reject-on-fail for users they don't know much about.
>
>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

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

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

if any receiver just blindly allows all mail from forwarders this too becomes a point of injection for spoofed addresses {if forwarder not rejecting on spf failure}

the intrinsic difference is if the spf record contains a bunch of ip's the mail is valid from followed by -all it should be accepted if it came from a forwarder {whitlisted} as it is likely it came to the forwarder via valid ip
{users problem if forwarder is not spf checking he should complain to forwarder about spoofs incomming}

if the spf record contains no valid ip's followed by -all {ie v=spf1 -all} the receiver should reject from anywhere including whitelisted forwarders as the envelope-from is invalid from anywhere {regardless of whether spf publisher uses SES/BATV or just static per-user spf or one record for the whole domain}

its really simple

same way mail from a whitelisted forwarder should only be considered exempt from -all match,
if it is envelope-to the user that whitelisted that forwarder

{as mail from that forwarder to any other user is not part of the forwarding setup and is thus just another spoof-attempt possibly by a provider that does user-forwards and unsanitized-outgoing-mail on the same machine}



>---- Michael Deutschmann <michael [at] talamasca>
>
>
>-------------------------------------------
>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


spfdiscuss at alandoherty

Jul 8, 2009, 7:10 AM

Post #16 of 35 (3423 views)
Permalink
Re: Senderside forwarder-problem mitigation [In reply to]
>+1
>
>I'm more focused on the use of SPF (plus DKIM signing) in the context
>of phishing.
>
>General rant (not directed at Scott):
>
>As a sender, if I publish a record that ends in -all and you, the
>receiver choose to pass mail claiming to be from one of my domains
>(that fails) to one of your endusers, I am going to point them in your
>direction when they contact me about that phishing email. I can't
>force you to any given behavior (King Canute invocation) but I can
>make sure that your endusers know that I have taken steps to provide
>you with clear information as to which IP addresses are authorized to
>send mail for particular domains.

agreed and if I do correctly only reject mail hitting -all when it comes from non-user whitelisted forwarders

and allow all from user whitelisted forwarders

i can if a spoof arrives still point the user at the forwarder they chose to use as the source problem
...
if i was a provider not whitelisting forwarders
and allowing mail even if matching -all from anywhere
to make up for my incompetence at dealing with forwarders
i would have to accept I was the issue

.................
there simply is no reason for spf to have to alter to deal with forwarders {being allowed through}
this is entirely down to running a competent receiver
.................

the only place where spf could IMHO be enhanced
is to deal with rejecting some clear spoofs even after whitelisted forwarder {where forwarder is ignoring spf}

and at idiot recievers not following -all from anywhere due to inability/unwillingness to whitelist their forwarders

and this is where the hardfail "v=spf1 stuff designating allowed ip's -all"
should be treated differently in spf parsers to the ALWAYSFAIL "v=spf1 -all" or as i keep suggesting "v=spfx {extrachar}all" or "v=spfx -any"

where the sender is indicating the address doesn't exist anywhere from any ip


i think the parser re-write should be trivial but standardised just an extra return code to spf1
and if a v=spf3 ever happens {to skip over senderid and possibly incorporate its functions into spf {to be utilized or ignored by publishers at their discresssion} it would be nice to have the extra syntax added



-------------------------------------------
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


vesely at tana

Jul 8, 2009, 7:43 AM

Post #17 of 35 (3420 views)
Permalink
Re: Senderside forwarder-problem mitigation [In reply to]
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.

> 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.

> 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.



-------------------------------------------
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


spfdiscuss at alandoherty

Jul 8, 2009, 8:41 AM

Post #18 of 35 (3436 views)
Permalink
Re: Senderside forwarder-problem mitigation [In reply to]
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


vesely at tana

Jul 8, 2009, 12:34 PM

Post #19 of 35 (3437 views)
Permalink
Re: Senderside forwarder-problem mitigation [In reply to]
alan wrote:
>>>all receivers MUST whitelist non-SRS forwarders [...]
>>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}

Yeah, when they're reasonable 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}

_How_ they accept whitelisting would also be a policy. It can go
anywhere from whitelisting an IP, to providing a specific
userid/password pair for the forwarder to use SUBMIT. None of those
can be easily automated, that's why I listed them last.

> 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}

What's wrong with a blank bounce address? If nobody is going to care
for bounces, it's perfect. Otherwise, the forwarder should consider
whether concealing the user's target address is the purpose of setting
up the forwarding. In that case, bouncing from the target is even less
advisable.

> 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

The latter is usually the best solution. Most modern mail client can
keep parallel connections to multiple IMAP/POP servers, so the
advantage of gathering everything to a single pickup point is not obvious.



-------------------------------------------
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


stuart at bmsi

Jul 8, 2009, 12:38 PM

Post #20 of 35 (3426 views)
Permalink
Re: Senderside forwarder-problem mitigation [In reply to]
On Wed, 8 Jul 2009, Michael Deutschmann wrote:

> In Gathman-SPF, SPF is applied by default after a forwarder whitelist has
> exempted part of the mailstream. No forwarder whitelist means no rejecting
> solely due to SPF fail. In this protocol, almost everyone can use -all
> senderside, but it is foolish for an mail admin who doesn't know his users
> well (such as in large ISPs) to deploy receiverside SPF checking that does
> more than header tagging.
>
> In Vessely-SPF, SPF is to be applied literally, with SPF fail being binding.
> In this protocol, only two groups are entitled to actually use -all
> senderside: SES/BATV users with a magic DNS server referenced in exists, and
> people who are desperate enough to stop backscatter that they will willingly
> risk rejected forwards. But receiver admins are assured that they can and
> should arm reject-on-fail for users they don't know much about.

V-SPF is a Receiver Policy helpfully provided by the Sender (RPS). SPFv1,
on the other hand, is a Sender Policy Framework. I see big technical
problems with V-SPF/RPS due the fact that senders can't possibly know
all the implementation details and company policies of all potential
receivers. And I see legal problems: what if a receiver doesn't execute the
V-SPF/RPS policy exactly?

--
Stuart D. Gathman <stuart [at] bmsi>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


-------------------------------------------
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


stuart at bmsi

Jul 8, 2009, 12:53 PM

Post #21 of 35 (3426 views)
Permalink
Re: Receiver forwarder-problem mitigation [In reply to]
On Wed, 8 Jul 2009, Alessandro Vesely wrote:

> _How_ they accept whitelisting would also be a policy. It can go anywhere from
> whitelisting an IP, to providing a specific userid/password pair for the
> forwarder to use SUBMIT. None of those can be easily automated, that's why I
> listed them last.

The simplest way to whitelist a forwarder is the way pymilter does it:
provide the domain of the forwarder - what the forwarder would
use if they were enlightened enough to use SRS. If the mail would have
passed SPF (or a guessed SPF policy such as "v=spf1 a mx ptr") had
the forwarder actually used SRS, then the email is from the whitelisted
forwarder.

One would hope the forwarder is at least enlighted enough
to publish an SPF record, or use a valid HELO or PTR that ends in their
domain or send from one of their MXes so the SPF-GUESS works.
If the forwarder is anonymous, maybe everyone is better off if the end user
*doesn't* get any of the forwards ... ;-)

--
Stuart D. Gathman <stuart [at] bmsi>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


-------------------------------------------
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


stuart at bmsi

Jul 8, 2009, 1:26 PM

Post #22 of 35 (3425 views)
Permalink
Re: Receiver forwarder-problem mitigation [In reply to]
On Wed, 8 Jul 2009, Stuart D. Gathman wrote:

> On Wed, 8 Jul 2009, Alessandro Vesely wrote:
>
> > _How_ they accept whitelisting would also be a policy. It can go anywhere from
> > whitelisting an IP, to providing a specific userid/password pair for the
> > forwarder to use SUBMIT. None of those can be easily automated, that's why I
> > listed them last.
>
> The simplest way to whitelist a forwarder is the way pymilter does it:
> provide the domain of the forwarder - what the forwarder would
> use if they were enlightened enough to use SRS. If the mail would have
> passed SPF (or a guessed SPF policy such as "v=spf1 a mx ptr") had
> the forwarder actually used SRS, then the email is from the whitelisted
> forwarder.
>
> One would hope the forwarder is at least enlighted enough
> to publish an SPF record, or use a valid HELO or PTR that ends in their
> domain or send from one of their MXes so the SPF-GUESS works.
> If the forwarder is anonymous, maybe everyone is better off if the end user
> *doesn't* get any of the forwards ... ;-)

An example might help:

Suppose Rick has a mailbox, rbrown [at] biguni, at his Uni. He graduates
and gets a job, and the Uni offers to forward his emails to his
new mailbox of rick_brown [at] bigcorp The forwarder domain is "biguni.edu".
(Hence the joke about an "anonymous forwarder" - which is almost certainly
spam since the domain was chosen arbitrarily by the sender.) The Uni
forwards email by replacing the RCPT TO and relaying to an MX for the
new RCPT TO.

The email admin at bigcorp.com adds biguni.edu to the list of forwarders
trusted by bigcorp.com. The mail system at bigcorp.com accepts email from IPs
that would get an SPF Pass or best-guess-pass with a mail from of
postmaster [at] biguni, without bothering to check SPF against the real MAIL
FROM (or checks only if real mailfrom fails to get a pass or precompiles
forwarder domain list to an IP set or ...).

--
Stuart D. Gathman <stuart [at] bmsi>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


-------------------------------------------
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


iane at sussex

Jul 9, 2009, 2:43 AM

Post #23 of 35 (3425 views)
Permalink
Re: Senderside forwarder-problem mitigation [In reply to]
--On 8 July 2009 16:43:56 +0200 Alessandro Vesely <vesely [at] tana> wrote:

> 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.

We do something similar, but not with SPF. We do something equivalent to
publishing ~all, but refusing mail from our local domain if it doesn't get
either a positive SPF pass, and hasn't been through our servers.

--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/


-------------------------------------------
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


michael at talamasca

Jul 9, 2009, 6:47 AM

Post #24 of 35 (3431 views)
Permalink
Re: Senderside forwarder-problem mitigation [In reply to]
On Wed, 8 Jul 2009, Stuart D. Gathman wrote:
> V-SPF is a Receiver Policy helpfully provided by the Sender (RPS). SPFv1,
> on the other hand, is a Sender Policy Framework. I see big technical
> problems with V-SPF/RPS due the fact that senders can't possibly know
> all the implementation details and company policies of all potential
> receivers.

I agree with you that G-SPF is the better protocol. But that's not the
argument.

The problem is that, like Microsoft SenderID, V-SPF is compromising the
effectiveness of G-SPF by leading senders to be timid in their SPF records.

And V-SPF is worse than SenderID in practice. Because we've been shouting
them down from the start, there are not likely many receivers who apply
v=spf1 records to PRA. Yet even today, some people on this very forum appear
to believe that V-SPF is the correct protocol, and G-SPF is the heresy.

Unfortunately, we're probably not going to really heal this mess until
v=spf3.... The root of the problem was the belief that traditional
forwarders would quickly die, making the distinction irrelevant. That was
quite arrogant in retrospect.

> And I see legal problems: what if a receiver doesn't execute the
> V-SPF/RPS policy exactly?

No legal force backs either V-SPF or G-SPF. The worst that can happen is
that the receiver gets blacklisted for emitting backscatter that should have
been stopped cold by V-SPF fail.

But since backscatterer.org already pounces on <> mails to spamtraps with
every possible SPF status except pass, that would make no difference.

---- Michael Deutschmann <michael [at] talamasca>


-------------------------------------------
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


vesely at tana

Jul 9, 2009, 10:34 AM

Post #25 of 35 (3430 views)
Permalink
Re: Receiver forwarder-problem mitigation [In reply to]
Stuart D. Gathman wrote:
>> The simplest way to whitelist a forwarder is the way pymilter does it:
>> provide the domain of the forwarder - what the forwarder would
>> use if they were enlightened enough to use SRS. If the mail would have
>> passed SPF (or a guessed SPF policy such as "v=spf1 a mx ptr") had
>> the forwarder actually used SRS, then the email is from the whitelisted
>> forwarder.

If that "guessed SPF" works correctly, perhaps the next version of SPF
should mention such default value and make it official.

> The email admin at bigcorp.com adds biguni.edu to the list of forwarders
> trusted by bigcorp.com. The mail system at bigcorp.com accepts email from IPs
> that would get an SPF Pass or best-guess-pass with a mail from of
> postmaster [at] biguni, without bothering to check SPF against the real MAIL
> FROM (or checks only if real mailfrom fails to get a pass or precompiles
> forwarder domain list to an IP set or ...).

A hack is a hack. For one, there is no administrative relationship
between mailout.biguni.edu and biguni.edu itself (rfc5507).



-------------------------------------------
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

First page Previous page 1 2 Next page Last page  View All SPF discuss RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.