Mailing List Archive

On Mon, 29 Jan 2007, Seth Goodman wrote:
> An interesting way to facilitate whitelisting. Unless you're proposing
> a new ESMTP extension or putting this information into the headers, this

Two new ESMTP extensions. (One for TENBOX/Authentication, and one for
TENBOX/Authorization).

> Forwarder whitelisting is another matter, as it suggests the forwarding
> domain is immune to spam complaints, and that's a much higher level of
> trust. I don't see a great deal of motivation for large recipient
> systems, who will often be the target of forwards, to whitelist such
> mail and then deal with spam complaints for messages they wouldn't have

You need to read over my root message in "The forwarder's perspective"
again. Basically, the superwhitelisting is "bait" to get forwarders to
implement their side of TENBOX, when they aren't motivated to do SRS.

Backscatter is a big problem for forwarders. TENBOX will make it go
away. SRS makes it worse, because by relaying the DSNs, the forwarder
takes the reputation hit for the recipient's backscatter.

---- Michael Deutschmann <michael@talamasca.ocis.net>

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Mon, 29 Jan 2007, Michael Deutschmann wrote:

> Backscatter is a big problem for forwarders. TENBOX will make it go
> away. SRS makes it worse, because by relaying the DSNs, the forwarder
> takes the reputation hit for the recipient's backscatter.

Not for domains that publish SPF -all, if they checked SPF before accepting the
mail on the way in.

--
Stuart D. Gathman <stuart@bmsi.com>
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/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Mon, 29 Jan 2007, Stuart D. Gathman wrote:
> On Mon, 29 Jan 2007, Michael Deutschmann wrote:
> > Backscatter is a big problem for forwarders. TENBOX will make it go
> > away. SRS makes it worse, because by relaying the DSNs, the forwarder
> > takes the reputation hit for the recipient's backscatter.
>
> Not for domains that publish SPF -all, if they checked SPF before
> accepting the mail on the way in.

But most domains don't publish SPF -all, or SPF at all, today. Faced
with an ambivalent SPF result (NONE, NEUTRAL, or SOFTFAIL), a forwarder
can neither reasonably refuse such e-mail outright, nor assume that
bouncing the message will be safe.

---- Michael Deutschmann <michael@talamasca.ocis.net>

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Saturday 03 February 2007 21:34, Michael Deutschmann wrote:
> On Mon, 29 Jan 2007, Stuart D. Gathman wrote:
> > On Mon, 29 Jan 2007, Michael Deutschmann wrote:
> > > Backscatter is a big problem for forwarders. TENBOX will make it go
> > > away. SRS makes it worse, because by relaying the DSNs, the forwarder
> > > takes the reputation hit for the recipient's backscatter.
> >
> > Not for domains that publish SPF -all, if they checked SPF before
> > accepting the mail on the way in.
>
> But most domains don't publish SPF -all, or SPF at all, today. Faced
> with an ambivalent SPF result (NONE, NEUTRAL, or SOFTFAIL), a forwarder
> can neither reasonably refuse such e-mail outright, nor assume that
> bouncing the message will be safe.
>
That's true, but they can also be assured that if they forward it it won't get
rejected for SPF downstream, so SPF makes this neither better nor worse.

I suppose one could do SRS if the message is SPF PASS, reject it if it's SPF
FAIL and do traditional forwarding if it's and other SPF result. This would
avoid the making it worse part and actually reduce backscatter to some
degree.

Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Sat, 3 Feb 2007, Scott Kitterman wrote:
> On Saturday 03 February 2007 21:34, Michael Deutschmann wrote:
> > But most domains don't publish SPF -all, or SPF at all, today. Faced
> > with an ambivalent SPF result (NONE, NEUTRAL, or SOFTFAIL), a forwarder
> > can neither reasonably refuse such e-mail outright, nor assume that
> > bouncing the message will be safe.
> >
> That's true, but they can also be assured that if they forward it it
> won't get rejected for SPF downstream, so SPF makes this neither better
> nor worse.
>
> I suppose one could do SRS if the message is SPF PASS, reject it if it's SPF
> FAIL and do traditional forwarding if it's and other SPF result. This would
> avoid the making it worse part and actually reduce backscatter to some
> degree.

Not necessarily. Just because the result was NEUTRAL or SOFTFAIL when
the forwarder checks incoming mail, does not mean the result can't be FAIL
when the ultimate recipient checks the same message against the forwarder's
outgoing mail IP.

So in some cases you need SRS to get through, but still can't safely
bounce.

---- Michael Deutschmann <michael@talamasca.ocis.net>

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Michael Deutschmann wrote:

>> I suppose one could do SRS if the message is SPF PASS, reject it if it's SPF
>> FAIL and do traditional forwarding if it's and other SPF result. This would
>> avoid the making it worse part and actually reduce backscatter to some degree

> Not necessarily. Just because the result was NEUTRAL or SOFTFAIL when
> the forwarder checks incoming mail, does not mean the result can't be FAIL
> when the ultimate recipient checks the same message against the forwarder's
> outgoing mail IP.

> So in some cases you need SRS to get through, but still can't safely bounce.

Yes, NEUTRAL isn't very helpful. When I see reports saying that xy% of all
mails already have SPF I often wonder what that actually means, how much of
the xy% is PASS or FAIL (or SOFTFAIL).

In theory it's possible to check outbound mail against your own sending IPs,
Julian invented that. SPF checks work best "at" the border, you can test it
on the sending side. MSAs could use this trick, if they wish to identify
plausible (no FAIL) envelope senders.

I'm not sure about forwarders, they could as well try to forward it and see
what happens at the next hop.

Frank


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Sun, 04 Feb 2007 09:03:37 +0100 Frank Ellermann
<nobody@xyzzy.claranet.de> wrote:
>Michael Deutschmann wrote:
>
>>> I suppose one could do SRS if the message is SPF PASS, reject it if
it's SPF
>>> FAIL and do traditional forwarding if it's and other SPF result. This
would
>>> avoid the making it worse part and actually reduce backscatter to some
degree
>
>> Not necessarily. Just because the result was NEUTRAL or SOFTFAIL when
>> the forwarder checks incoming mail, does not mean the result can't be
FAIL
>> when the ultimate recipient checks the same message against the
forwarder's
>> outgoing mail IP.
>
>> So in some cases you need SRS to get through, but still can't safely
bounce.
>
>Yes, NEUTRAL isn't very helpful. When I see reports saying that xy% of all
>mails already have SPF I often wonder what that actually means, how much of
>the xy% is PASS or FAIL (or SOFTFAIL).
>
>In theory it's possible to check outbound mail against your own sending
IPs,
>Julian invented that. SPF checks work best "at" the border, you can test
it
>on the sending side. MSAs could use this trick, if they wish to identify
>plausible (no FAIL) envelope senders.
>
>I'm not sure about forwarders, they could as well try to forward it and see
>what happens at the next hop.
>
Not just theory. My controlledmail.com MTAs all do this.

Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frank Ellermann wrote:
> In theory it's possible to check outbound mail against your own sending
> IPs, Julian invented that.

While I am a proponent of outbound SPF checking, it was NOT me who invented
it. (Unfortunately, I don't remember who did.) In any case, no credit
where no credit is due.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFxd0pwL7PKlBZWjsRAqRbAJ92qnwE8RIyGv2DHM6YHdyg6rAf7ACdFTbu
m+rOQtzqjs7t9F0lgzvhitg=
=Adod
-----END PGP SIGNATURE-----

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Frank Ellermann wrote on Sunday, February 04, 2007 2:04 AM -0600:

> In theory it's possible to check outbound mail against your own
> sending IPs, Julian invented that. SPF checks work best "at"
> the border, you can test it on the sending side. MSAs could
> use this trick, if they wish to identify plausible (no FAIL)
> envelope senders.

Sure, but the MSA needs to have a list of acceptable return-path
domains, and preferably a list of mailboxes with their required
authentication credentials, regardless of what external domain owners
publish. Since you need that list anyway to keep you from open
relaying, SPF checking is redundant for this purpose. It does identify
potential rejections at the recipient, which is a reasonable thing to
do.

--
Seth Goodman

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Scott Kitterman wrote:

> Not just theory. My controlledmail.com MTAs all do this.

Julian wrote:

|> In theory it's possible to check outbound mail against your own
|> sending IPs, Julian invented that.

| While I am a proponent of outbound SPF checking, it was NOT me who
| invented it. (Unfortunately, I don't remember who did.) In any
| case, no credit where no credit is due.

Scott, was it your idea ? If not maybe it was Ralf Döblitz.

Frank


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Seth Goodman wrote:

>> MSAs could use this trick, if they wish to identify plausible (no FAIL)
>> envelope senders.

> Sure, but the MSA needs to have a list of acceptable return-path
> domains, and preferably a list of mailboxes with their required
> authentication credentials, regardless of what external domain owners
> publish.

Not necessarily, the famous "enforced submission rights" in RFC 4409
are only an OPTION. Any MSA "MUST" (in 4409) have some kind of AUTH,
to identify users AUTHorized to use the MSA. That could be anything
from SMTP-after-POP over RADIUS to SMTP AUTH (2554bis).

Which Return-Path AUTHorized users are permitted to use can be a very
different question. SPF PASS is a possible solution to figure it out.

Probably not good enough for op=auth, for that you'd really need a
list. Or anything with the same effect, a big ISP could just demand
that users have to use the MAIL FROM:<their.mailbox@this.isp.example>

> Since you need that list anyway to keep you from open relaying, SPF
> checking is redundant for this purpose.

IMO it's s/Since/If/

Frank


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Sun, 04 Feb 2007 19:31:13 +0100 Frank Ellermann <nobody@xyzzy.claranet.de> wrote:
>Scott Kitterman wrote:
>
>> Not just theory. My controlledmail.com MTAs all do this.
>
>Julian wrote:
>
>|> In theory it's possible to check outbound mail against your own
>|> sending IPs, Julian invented that.
>
>| While I am a proponent of outbound SPF checking, it was NOT me who
>| invented it. (Unfortunately, I don't remember who did.) In any
>| case, no credit where no credit is due.
>
>Scott, was it your idea ? If not maybe it was Ralf Döblitz.
>
IIRC it was me. Forwarders could use this in combination with your (I think it was you) idea for 550 not local.

Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Scott Kitterman wrote:

> Forwarders could use this in combination with your (I think it was
> you) idea for 550 not local.

Okay, readjusting the credits for "outbound SPF", but "551 not local"
isn't my idea, that's in Jon Postel's RFC 821 :-)

Frank


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Frank Ellermann wrote on Sunday, February 04, 2007 12:57 PM -0600:

> Seth Goodman wrote:
>
> > Frank Ellermann wrote:
> >
> > > MSAs could use this trick, if they wish to identify plausible (no
> > > FAIL) envelope senders.
>
> > Sure, but the MSA needs to have a list of acceptable return-path
> > domains, and preferably a list of mailboxes with their required
> > authentication credentials, regardless of what external domain
> > owners publish.
>
> Not necessarily, the famous "enforced submission rights" in RFC 4409
> are only an OPTION. Any MSA "MUST" (in 4409) have some kind of AUTH,
> to identify users AUTHorized to use the MSA. That could be anything
> from SMTP-after-POP over RADIUS to SMTP AUTH (2554bis).

This is true, they don't have to do anything except avoid being listed
as an open relay. They do authentication to restrict access, but don't
restrict submission rights and only act when they receive complaints.
Plenty of large systems still permit sender forgery, ostensibly because
most of their users submit over port 25, which is often blocked by
outside networks when their users travel. It's ironic that these same
systems also block port 25 for users visiting their network space. I
hope we're not still discussing this same chicken vs. egg problem ten
years from now.


>
> Which Return-Path AUTHorized users are permitted to use can be a very
> different question. SPF PASS is a possible solution to figure it out.
>
> Probably not good enough for op=auth, for that you'd really need a
> list. Or anything with the same effect, a big ISP could just demand
> that users have to use the MAIL FROM:<their.mailbox@this.isp.example>

Once they move their mail submission off port 25, it's a small step to
limit address usage. This change has gone much slower than I would have
guessed. The increased usage of web mail has removed some of the
impetus for this.


>
> > Since you need that list anyway to keep you from open relaying, SPF
> > checking is redundant for this purpose.
>
> IMO it's s/Since/If/

Agreed, many large systems prevent open relaying by authenticating users
without enforcing submission rights. Better to not confuse what is with
what should be.

Still, I don't see what advantage SPF provides over an ACL to control
the addresses your own users claim. Checking SPF on outbound would
inform you of possible rejections at the recipient, which will hopefully
become more important.

--
Seth Goodman

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Sunday 04 February 2007 18:36, Seth Goodman wrote:
> Frank Ellermann wrote on Sunday, February 04, 2007 12:57 PM -0600:

> > Not necessarily, the famous "enforced submission rights" in RFC 4409
> > are only an OPTION. Any MSA "MUST" (in 4409) have some kind of AUTH,
> > to identify users AUTHorized to use the MSA. That could be anything
> > from SMTP-after-POP over RADIUS to SMTP AUTH (2554bis).
>
> This is true, they don't have to do anything except avoid being listed
> as an open relay. They do authentication to restrict access, but don't
> restrict submission rights and only act when they receive complaints.
> Plenty of large systems still permit sender forgery, ostensibly because
> most of their users submit over port 25, which is often blocked by
> outside networks when their users travel. It's ironic that these same
> systems also block port 25 for users visiting their network space. I
> hope we're not still discussing this same chicken vs. egg problem ten
> years from now.
>
The tricky part about this is not the technical aspects, but the
administrative/procedural part. If you have a legacy userbase of
thousands/millions how to you go back and validate which mail from identities
they should be using. This is a non-trivial problem.

For an MSA that has implemented appropriate technical restrictions, I agree
that the prospective SPF check is largely redundant. At controlledmail.com I
still do it despite having plenty of other protections in part to detect
errors in customer SPF records (I don't insist they have them, but mail
doesn't depart may server if there is SPF and it's not a PASS) and in part as
a redundant check in case something goes wrong (I believe in a belt and
suspenders approach to security).

The prospective SPF check is an easily implemented check that would prevent
much forgery coming from large ISPs without the administrative burden of
validating their entire userbase. It also gives them an easy answer if
someone complains about forgery from ther network (publish a proper SPF
record and it'll stop).

Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On 05/02/07, Scott Kitterman <scott@kitterman.com> wrote:
> On Sunday 04 February 2007 18:36, Seth Goodman wrote:
> > Frank Ellermann wrote on Sunday, February 04, 2007 12:57 PM -0600:
>
> > > Not necessarily, the famous "enforced submission rights" in RFC 4409
> > > are only an OPTION. Any MSA "MUST" (in 4409) have some kind of AUTH,
> > > to identify users AUTHorized to use the MSA. That could be anything
> > > from SMTP-after-POP over RADIUS to SMTP AUTH (2554bis).
> >
> > This is true, they don't have to do anything except avoid being listed
> > as an open relay. They do authentication to restrict access, but don't
> > restrict submission rights and only act when they receive complaints.
> > Plenty of large systems still permit sender forgery, ostensibly because
> > most of their users submit over port 25, which is often blocked by
> > outside networks whn their users travel. It's ironic that these same
> > systems also block port 25 for users visiting their network space. I
> > hope we're not still discussing this same chicken vs. egg problem ten
> > years from now.
> >
> The tricky part about this is not the technical aspects, but the
> administrative/procedural part. If you have a legacy userbase of
> thousands/millions how to you go back and validate which mail from identities
> they should be using. This is a non-trivial problem.

Yep. I know initmately the email instructure of a major European ISP
with operations in 4 countries, and it would be the complete opposite
of trivial to implement this in their network. The MSA (which they
don't have in port-587 sense, they have port 25 firewalled-off to
their own IP space instead) has no knowledge of the identity of the
connecting customer; any form of user database it might use to do
authentication is not even in the same country.

Bad architecture? Sure. But they can only start from where they are.

Peter


--
Peter Bowyer
Email: peter@bowyer.org

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Sat, 3 Feb 2007, Michael Deutschmann wrote:

> > I suppose one could do SRS if the message is SPF PASS, reject it if it's SPF
> > FAIL and do traditional forwarding if it's and other SPF result. This would
> > avoid the making it worse part and actually reduce backscatter to some
> > degree.
>
> Not necessarily. Just because the result was NEUTRAL or SOFTFAIL when
> the forwarder checks incoming mail, does not mean the result can't be FAIL
> when the ultimate recipient checks the same message against the forwarder's
> outgoing mail IP.
>
> So in some cases you need SRS to get through, but still can't safely
> bounce.

three things:

1) The recipient MUST NOT check spf for non-SRS forwarders. If they
don't know who their forwarders are, then they MUST NOT check SPF at all. Of
course, they probably will anyway, so ...

2) The forwarder MAY rerun check_spf with his own IP. If the result
is FAIL, then use SRS, or drop the mail (possibly with a DSN to the
alleged sender summarizing the situation. The DSN can be easily filtered by
savvy senders using MAIL FROM signing, e.g. SRS.)

3) The forwarder MAY just try the next hop, and if rejected, try again
with SRS.

--
Stuart D. Gathman <stuart@bmsi.com>
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/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Scott Kitterman wrote on Monday, February 05, 2007 12:04 AM -0600:

> The tricky part about this is not the technical aspects, but the
> administrative/procedural part. If you have a legacy userbase of
> thousands/millions how to you go back and validate which mail from
> identities they should be using. This is a non-trivial problem.

That's true in the general case of users with arbitrary outbound
addresses that have no correspondence to their incoming addresses. It's
also true for the case that Peter mentions where the underlying
architecture is unfriendly to authentication. For the most important
case, where inbound and outbound addresses are the same, the solution is
reasonable, as Frank suggests. It still doesn't address some users'
desire to submit mail with an identity they control on another network
that doesn't support authenticated submission. The problem is at
another service you can't control, so it's another chicken vs. egg
situation.

Moreover, what is the problem we are trying to fix? Services have
little interest in preventing their users from forging domains belonging
to someone else. SPF checking on incoming is in the recipient's
interest, which is why they _may_ eventually do it. Outbound SPF
checking is highly responsible, but not particularly in the sender's
interest. It's similar to outbound virus filtering and rate limiting,
except that the best practice of outbound authentication makes it
redundant. If you want to say it's better than doing nothing, I'd
agree.


>
> For an MSA that has implemented appropriate technical restrictions, I
> agree that the prospective SPF check is largely redundant.

It's important to state that. This works best for small systems with no
outbound authentication who wish to limit their users forging foreign
domains that publish SPF records.


> The prospective SPF check is an easily implemented check that would
> prevent much forgery coming from large ISPs without the administrative
> burden of validating their entire userbase. It also gives them an
easy
> answer if someone complains about forgery from ther network (publish a
> proper SPF record and it'll stop).

It actually wouldn't prevent much forgery at large domains, as this
method allows all of their users free use of any domain designating
those MTA's. It only prevents the customers of large services from
forging domains belonging to users of _other_ services, which is not
very interesting to them. They see their current measures, which
consist of booting users after they commit forgery and abuse other
systems, as adequate for their needs.

--
Seth Goodman

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Mon, 5 Feb 2007, Seth Goodman wrote:

> > For an MSA that has implemented appropriate technical restrictions, I
> > agree that the prospective SPF check is largely redundant.
>
> It's important to state that. This works best for small systems with no
> outbound authentication who wish to limit their users forging foreign
> domains that publish SPF records.

In pymilter, internal PCs attempting to send with foreign domains
are labeled "zombies". Too many such forgeries, and that PC (IP) is
cut off from sending email. User has to run malware cleaning software
and write "I will not download free screensavers" on the blackboard
100 times before I reenable their email.

--
Stuart D. Gathman <stuart@bmsi.com>
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/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Stuart D. Gathman wrote on Monday, February 05, 2007 1:24 PM -0500:

> On Mon, 5 Feb 2007, Seth Goodman wrote:
>
> > Scott Kitterman wrote on Monday, February 05, 2007 1:04 AM -0500:
> >
> > > For an MSA that has implemented appropriate technical
> > > restrictions, I agree that the prospective SPF check is largely
> > > redundant.
> >
> > It's important to state that. This works best for small systems
> > with no outbound authentication who wish to limit their users
> > forging foreign domains that publish SPF records.
>
> In pymilter, internal PCs attempting to send with foreign domains
> are labeled "zombies". Too many such forgeries, and that PC (IP) is
> cut off from sending email. User has to run malware cleaning software
> and write "I will not download free screensavers" on the blackboard
> 100 times before I reenable their email.

This is very good for small numbers of users. If you had sufficient
users, the folks who control the botnets could accomplish what they need
by forging other users' identities, or even by publishing legitimate SPF
records that designate your outbound hosts. This will affect the
reputation of your IP's, even though you never gave the domain owners
permission to use them. I know, that's no longer domain forgery and we
shouldn't talk about IP reputation on the SPF list. Unfortunately, if
SPF encourages an MSA to accept messages it shouldn't, SPF gets the
blame, even though no one ever claimed it does anything but detect
certain domain forgeries. We should be recommending that MSA's enforce
submission rights instead. That stops outbound sender identity forgery
and protects the reputation of every domain you intentionally emit mail
for, and makes sure you emit mail for no others.

There are a lot of good excuses, along with some reasons, why this is
difficult for a large existing user base. It's much harder to make that
argument for new customers.

--
Seth Goodman

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Mon, 5 Feb 2007, Seth Goodman wrote:

> > In pymilter, internal PCs attempting to send with foreign domains
> > are labeled "zombies". Too many such forgeries, and that PC (IP) is
> > cut off from sending email. User has to run malware cleaning software
> > and write "I will not download free screensavers" on the blackboard
> > 100 times before I reenable their email.
>
> This is very good for small numbers of users. If you had sufficient
> users, the folks who control the botnets could accomplish what they need
> by forging other users' identities, or even by publishing legitimate SPF
> records that designate your outbound hosts. This will affect the
> reputation of your IP's, even though you never gave the domain owners
> permission to use them. I know, that's no longer domain forgery and we

The "internal_domains" config option lists which domains internal users
are allowed to use. But you are right, the setup doesn't scale. It
needs a database mapping users to allowed domains. Easy enough to add
if I ever am asked to handle such a setup. Users can be identified by
IP or SMTP AUTH.

--
Stuart D. Gathman <stuart@bmsi.com>
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/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On 05/02/07, Stuart D. Gathman <stuart@bmsi.com> wrote:
> On Sat, 3 Feb 2007, Michael Deutschmann wrote:
>
> > > I suppose one could do SRS if the message is SPF PASS, reject it if it's SPF
> > > FAIL and do traditional forwarding if it's and other SPF result. This would
> > > avoid the making it worse part and actually reduce backscatter to some
> > > degree.
> >
> > Not necessarily. Just because the result was NEUTRAL or SOFTFAIL when
> > the forwarder checks incoming mail, does not mean the result can't be FAIL
> > when the ultimate recipient checks the same message against the forwarder's
> > outgoing mail IP.
> >
> > So in some cases you need SRS to get through, but still can't safely
> > bounce.
>
> three things:
>
> 1) The recipient MUST NOT check spf for non-SRS forwarders. If they
> don't know who their forwarders are, then they MUST NOT check SPF at all. Of
> course, they probably will anyway, so ...

But the recipient (as an administrative entity) often isn't aware of
the status of a forwarder. There's a non-trivial and pretty flaky
people process involved if the administrator is to know about every
friendly forwarder that one of their users might have signed up with.

In the absense of this, there's no way to differentiate a forwarder
from a forger.

So I don't believe your 'MUST NOT's above are achievable in the wild.

> 2) The forwarder MAY rerun check_spf with his own IP. If the result
> is FAIL, then use SRS, or drop the mail (possibly with a DSN to the
> alleged sender summarizing the situation. The DSN can be easily filtered by
> savvy senders using MAIL FROM signing, e.g. SRS.)

This seems pretty sensible - I'm certianly going to look at
implementing on a forwarder I run.

>
> 3) The forwarder MAY just try the next hop, and if rejected, try again
> with SRS.

What's the benefit of this over just-use-SRS?

Peter

--
Peter Bowyer
Email: peter@bowyer.org

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Seth Goodman wrote:

> We should be recommending that MSA's enforce submission rights instead.

Yes, and we do that already:

http://tools.ietf.org/html/rfc4408#section-10.4
http://tools.ietf.org/html/draft-ellermann-spf-options-01#section-3.4

Frank

P.S.: waiting for round tuits, I'll fix the op= I-D wrt include: etc.


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Tue, 6 Feb 2007, Peter Bowyer wrote:

> > 3) The forwarder MAY just try the next hop, and if rejected, try again
> > with SRS.
>
> What's the benefit of this over just-use-SRS?

If the receiver is tracking domain reputation, you would like the
original sender domain to get any spam demerits - i.e. a forwarder
would like to avoid SRS whenever possible. IP reputation is the
same in both cases, and you shouldn't get any demerits for a
rejection.

--
Stuart D. Gathman <stuart@bmsi.com>
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/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On 06/02/07, Stuart D. Gathman <stuart@bmsi.com> wrote:
> On Tue, 6 Feb 2007, Peter Bowyer wrote:
>
> > > 3) The forwarder MAY just try the next hop, and if rejected, try again
> > > with SRS.
> >
> > What's the benefit of this over just-use-SRS?
>
> If the receiver is tracking domain reputation, you would like the
> original sender domain to get any spam demerits - i.e. a forwarder
> would like to avoid SRS whenever possible. IP reputation is the
> same in both cases, and you shouldn't get any demerits for a
> rejection.

Yep, understood - thanks.


--
Peter Bowyer
Email: peter@bowyer.org

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735