spf-discuss
[Top] [All Lists]

RE: Re: Unified SPF works in progress now in alpha

2004-07-07 06:51:35
From: Frank Ellermann
Sent: Tuesday, July 06, 2004 4:09 PM


Seth Goodman wrote:

"most" doesn't include users with a reliable MX (static IP),
and a say DynDNS domain with "v=spf1 +a +mx -all" policy.

I specifically said the problem was with dynamic IP's as
you've quoted me above.  Of course this does not include
static IP's.

Sorry, probably my answer was unclear:  I was talking about a
user with dialup IP (dynamic IP) sending his mail directly to
the MX of the recipient.  This same user can have a 3rd party
as MX, with a static IP for this MX.

IMHO this _could_ be good enough for reliable mail solutions.
DynDNS offers this solution, with their own MX services, or
with a 3rd party MX provider.

As long as they submit their mail through an MTA with a static IP, that's
accountability.  This is exactly the same as using an ISP's smarthost.  I'm
not suggesting that people on dynamic IP's can't run an MSA, but they
shouldn't run an MTA.  That's an important distinction.  Anyone who dislikes
forgeries and spam generally refuses any mail coming out of dynamic IP's.
It's one of the best spam rejecters there is.  One of our biggest problems
is huge providers, like Comcast, that give their dynamic IP customers
unfettered port 25 access outside their network.  Hopefully, a few more
years of lobbying and we can close that hole and our spam loads will go way
down.  Why would we want to put in place a mechanism for people to continue
to abuse that hole?


http://spf.pobox.com/slides/unified%20spf/0429.html

Tnx, yes, that's some kind of "bypass comcast.blackholes.us
for me please" scheme.  And IMHO it's okay, this user says
that the sender policy for his domain does not follow the
defaults defined by his ISP.

I think this is definitely not OK.  It's not a matter of the ISP's defaults,
it's the ISP's AUP expressed in their SPF record.  The ISP owns the netblock
and the user agrees to an AUP for a given grade of service.  We have no
business helping anyone circumvent a netblock owners' stated policy on the
permitted use of their IP space.  Their netblock, their rules.  This is
analogous to cable box descramblers that circumvent cable TV charges.  I
don't have any love for cable companies, but this kind of activity is just
plain wrong, and it is equally wrong in the ISP context.


Now you as recipient have to decide what you want, MTAMARK or
sender policy.

Unified SPF allows both.  As a recipient, we can check both.  Careful
recipients _will_ check both.

As long as spammers don't use this construct
you could still accept the explicit sender policy.

Spammers can and will use this construct, should we provide it.


Let's assume that I'm a spammer and want to abuse this feature:
1 - I'd need a domain allowing something like "v=spf1 a -all"
2 - a service like DynDNS allowing to publish my dyn. IP for
    this domain
3 - an ISP saying "this IP is not normally used for mail" (or
    an equivalent entry in a DNSBL used by the recipient)

That's a dilemma.  But at least you could trust that all spam
sent from me comes with a valid sender policy.  In the case of
DynDNS you could kill my account with a spam report, and the
"custom DNS" accounts allowing sender policies are _not_ free.

It's bad enough that spammers can circumvent SPF by using disposable
domains.  The combination of disposable domains and dynamic IP's gives them
an edge that will be hard to beat.  Dynamic DNS service is cheap enough that
it is in the disposable category.

Furthermore, we have constructed a policy engine that allows spammers to
circumvent the netblock owners' wishes.  All this for the sake of vanity
domain hobbyists who are unwilling to pay for the services they wish to use.
We don't have to bend over backwards to support this group, which
incidentally includes lots of script kiddies.  I'm much more interested in
stopping forgeries than allowing anyone to send email from any machine
claiming any return-path under any circumstances.  While that policy made
sense in the Internet of the early 1980's, it doesn't today.  I'm sorry if
this is inconvenient for hobbyists, but there are more important concerns on
the table.


If you have a dynamic IP, you shouldn't be running an MTA
because you cannot be held accountable for what you send out.

If the functions "send" and "receive" (MX) are split, there's
no technical problem with this setup.  I'd get all bounces and
normal replies via the MX.  And I'm accoutable for my actions
at abuse(_at_)dyndns / abuse(_at_)myISP / abuse(_at_)myMX

If you are sending through a static IP, than an abuse mail to the owner of
that static IP could be expected to be helpful.  The IP can also be
blacklisted, which is the quickest way to get a problem solved.  That is why
static IP's are the way to go.  If you are sending mail from a vanity
domain, we don't necessarily know your ISP, as headers are easily forged.
As far as abuse(_at_)yourMX, that's like sending a complaint to
abuse(_at_)enlarge-it(_dot_)com(_dot_)  I don't call that accountability.

Sending IP's need to be static because that's the only way they can be
blacklisted.  Blacklisting shuts down spam sources.  Dynamic IP's _cannot_
be blacklisted, and that's why they're not accountable.


Dynamic IP's inherently have no accountability.

That's IMHO not the case.  You don't have a problem with "me"
(in my example), you have a problem with Spamcast (in your
scenario).  But you know this already, it's nothing new, and
not related to (classic or united) SPF.

Spam is about behavior, not content.  I have a problem with any MTA that
sends out UBE.  If that MTA is not on a static IP, it is very hard to shut
them down.  It relates to SPF if a netblock owner says, "there is no
legitimate mail coming from this netblock", and we provide a mechanism to
say, "it does for _my_ domain".  A domain owner can't dictate the use of
someone else's netblock and SPF shouldn't support that functionality.


My point was that we shouldn't provide a mechanism for
people on dynamic IP's to get around their own ISP's
reasonable restrictions on that type of service.

I'm still not convinced, it's my mail and my sender policy.

It's your _domain_, so the policy you control concerns the use of the domain
name.  The connection belongs to the ISP and they determine the types of
services, volume of traffic, etc. that the connection can carry.  If you
agreed to an AUP that stipulates that you cannot run an MTA on your
connection, then you can't.  The same goes for a web server or DNS server,
but that has nothing to do with SPF.


If I really use a dynamic IP to send mail directly, then I
should be able to say so, just like I'm able to say "+all".

Not if the netblock owner has stated policy to the contrary.  I can see why
you want to do this, but if the netblock owner forbids it, you would be
stealing their services.  That is contrary to the mission of SPF.


You as recipient are free to accept this, or to reject it
based on other evidence like MTAMARK or a DUL.  Maybe your
objection is only the "trumps", and in that case just read
"could trump".  It's only a slide, not a MUST in some RfC.

I'm afraid that doesn't cut it.  It needs to be "MUST NOT TRUMP".  We have
been consistently complaining about how the root of the spam problem is in
netblock owners failure to enforce reasonable policy.  If SPF becomes an
engine for circumventing netblock owners' legitimate policy statements, we
will become part of the problem, not the solution.

--

Seth Goodman