Subject: RE: [Asrg] Re: SPF abused by spammers

From: "Sauer, Damon" <[email-masked]>
Date: Tue, 14 Sep 2004 11:28:53 -0500

> On September 11, 2004 at 11:56 [email-masked] (Matthias 
> Leisi) wrote:
>  > $DIALUP_ISP that adds it's whole dialup-range as "legitimate 
>  > mailservers" for $DIALUP_DOMAIN is of course free to do 
> so, but that 
>  > would be less-than-intelligent.
> 
> So your point relies on $D* never doing anything that is
> less-than-intelligent?
> 

This is your opinion and you are welcome to it. This is not a technical
fact.

> But this isn't a technical hurdle, merely a presumption about how $D*
> might behave.
> 

 I am sure that the $D will do what is in it's best interest. Mute
point.

[snip]
> They may have little choice, from their point of view, either because
> they perceive this as a marketing aspect (why don't they block port 25
> now?), or their economic/business model doesn't allow for the sort of
> e-mail infrastructure which provides for officially relays. Or, more
> likely, a little of each (since one policy tends to lead to the
> other.)

Another broad based assumption. Many IP's do not close port 25 due to
technical issues surrounding network IP assignments and Subletted IP
block ranges.
SPF will allow them to limit these without having to resort to
expensive, difficult and time consuming network changes.
Ooops... did I just bring up a new benefit to SPF? 

[snip]
> 
> Can't wanadoo.fr publish an SPF record allowing
> ABordeaux-251-2-10-162.w82-125.abo.wanadoo.fr to send email directly?
> 
> Not "are they likely to", or "it wouldn't seem to be in their best
> interest", but just: Can they or not?
> 
> I admit I might be missing something here but thus far it's been like
> grabbing smoke trying to get to the bottom of this.
> 

 I do not speak for wanadoo or any other ISP. It seems to me that it
could tie in with my previous statement, in that an ISP could package an
SPF record as "value-add".

Regards,
Damon Sauer

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Markus Stumpf <[email-masked]>
Date: Tue, 14 Sep 2004 19:19:45 +0200

> technical issues surrounding network IP assignments and Subletted IP

ACK.

> expensive, difficult and time consuming network changes.

Could you explain this a bit more in detail? How could a ISP use
SPF to limit port 25 connections?

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

---

From: Daniel Feenberg <[email-masked]>
Date: Tue, 14 Sep 2004 15:59:37 -0400 (EDT)

> SPF to limit port 25 connections?

I have another question - Even given that an ISP might not want to close
port 25 outbound from its dynamic address customers at the router level,
what advantage does SPF have over merely informing MAPS/Spamhaus, etc of
its dialup ranges? Those services already exist and are widely used,
while SPF is in infancy. Notice I ask what advantage, not what difference,
as I realize that in one case the authorization is by the IP address
ownership, and in the other by domain name ownership. In this discussion,
however, both have been owned by the same party (the ISP, $D).

The only way I can understand SPF is as a way to distinguish spam from
non-spam on a single sending MTA. If the ISP thinks a host sends only
spam, aren't there are easier ways to deal with the situation?

---

From: Devdas Bhagat <[email-masked]>
Date: Wed, 15 Sep 2004 02:55:51 +0530

On 14/09/04 15:59 -0400, Daniel Feenberg wrote:
<snip>
> spam, aren't there are easier ways to deal with the situation?

Right. Think of SPF as a reversed MX record for a given domain, and the
situation becomes clearer.

The cost of breaking .forward, IMO, outweighs the advantages that SPF
offers.

If SPF becomes commonly used, then blocking by domain will become more
effective, rather than the current practice of blocking by IP (which is
already very effective).

Devdas Bhagat

---

From: Seth Breidbart <[email-masked]>
Date: Tue, 14 Sep 2004 19:37:24 -0400 (EDT)

Daniel Feenberg <[email-masked]> wrote:

> I have another question - Even given that an ISP might not want to
> close port 25 outbound from its dynamic address customers at the
> router level, what advantage does SPF have over merely informing
> MAPS/Spamhaus, etc of its dialup ranges?

Suppose I own cluebytwelve.com (I do), and I want to send mail "from
[email-masked]" from my home computer.  I can set up an SPF
record for cluebytwelve.com to specify that my current IP address has
that permission, completely independent of the ISP that provides
IP-level access.  That works well for me, even though the ISP doesn't
authorize my home machine to send directly email from "sethb@ISP".

Seth

---

From: [email-masked]
Date: Wed, 15 Sep 2004 22:36:41 -0400

On Tue, Sep 14, 2004 at 07:37:24PM -0400, Seth Breidbart wrote

> authorize my home machine to send directly email from "sethb@ISP".

  I suppose there's nothing preventing DynDNS etal from extending their
current dynamic DNS service to offer SPF records.

  Technical question; does SPF authorize an IP address, a forward DNS,
or an rDNS to send email for a given domain?

-- 
Walter Dnes <[email-masked]>
Email users are divided into two classes;
1) Those who have effective spam-blocking
2) Those who wish they did

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 16 Sep 2004 23:55:21 +0200

[email-masked] wrote:
 
> I suppose there's nothing preventing DynDNS etal from
> extending their current dynamic DNS service to offer SPF
> records.

They do in their "custom" system.  Not in the free "dyndns"
system.

> Technical question

<http://spf.pobox.com/mechanism.html>  Ignore the less
trivial "exists", "include", and macros to get the idea.

It's still the same list of mechanisms in the current
MARID SPF protocol draft, published yesterday (08-15):
 
<http://www.ietf.org/internet-drafts/draft-ietf-marid-protocol-03.txt>

                     Bye, Frank