Subject: Re: [Asrg] article: port 25 blocking

From: Markus Stumpf <[email-masked]>
Date: Wed, 13 Apr 2005 01:17:22 +0200

On Tue, Apr 12, 2005 at 02:50:00PM -0700, George Ou wrote:
> >Sorry, this is not how SPF works.
> 
> Says who?

Says me.

> SPF blocks all hosts that are not registered as SMTP servers in
> their domain's authoritative DNS servers.  That DOES make blocking consumer
> outbound 25 moot.

No. *sigh*

> >Nothing prevents a spammer from getting throwaway domains, adding TTL 300
> > SPF records and using some 10000 cracked hosts on broadband access to spam.
> 
> I never claimed SPF stops spammers from using stolen SMTP credentials.

But you claim SPF makes port 25 blocking moot. To me there is some kind of
antagonism in this.

> This
> same issue applies to port 25 blocking as well.

No, it does not apply to port 25 blocking as well.
Port 25 blocking stops dull spammers, stops dull viruses, stops dull botnets
and stops misconfigured hosts. It stops unauthenticated mail injection (usually),
besides for smarthosts.
You can't turn a host behind a port 25 block into something that pretends to be a
mailserver and makes connections to other mailservers as it were itself a mailserver.

SPF does all this NOT and it breaks widely deployed Internet Mail Infrastructure.

> SPF does make it possible
> to block abusive or irresponsible domains.

If this domain uses SPF records, yes. If it doesn't you have the same situation
as you have now. With less than 0.01% of all domains using SPF records really a
big win. Deployment is the problem. Without > 80% of all domains deploying SPF
(and SRS) I will never block based on SPF, because I have better things to do
than to talk to 500 business customers a day and explain them 100 times why the
eMail from a SPF -all didn't reach them.

Do you have customers? Do you manage domains for them? Choose 100. Call them and
ask them for information that is needed to add correct and usable SPF records.
Come back in 4 weeks and tell us your results. Call them again in 6 months and
look how much of the information is still accurate.
We're managing only about 20-40000 domains. We have direct customers, we have
resellers. Adding useful SPF records will take *ages*:
    250 working days a year. 
    8 working hours a day
    4 domains per hour (*very* optimistic)
This makes 8000 domains per one person per year. With 30000 domain this will make
3.75 years for one person or about 1 year for 4-5 persons. And: this staff has to
be skilled.  They have to understand: what is SPF, how emails work, what IP addresses
are and they have to be able to ask the correct questions and you need large databases
of mailservers, because if the customer says: "I am using provider EXAMPLE",
you have to know the IP addresses of the outgoing mailservers and you need *tight*
inter-ISP communication, because you have to change SPF records if the other
ISP changes MTA addresses. As to my knowledge there are currently NO such lists.
So before starting the "SPF-for-every-domain" project we should probably start the
"every-ISP-lists-its-mailservers" project (dooh, this would be a MTAMARK like
list).

Who will pay for this? With USD 5 or 6 for a domain how to do fund the 15-30 minutes
it takes to query the customer for SPF records and add them?

Reality bites.

*sigh* We've been through this a 100 times on this list and on MARID.
Is this Groundhog Day or what?

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

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

---

From: "George Ou" <[email-masked]>
Date: Tue, 12 Apr 2005 16:41:28 -0700

-----Original Message-----
From: Markus Stumpf [mailto:[email-masked]] 
Sent: Tuesday, April 12, 2005 4:17 PM
To: George Ou
Cc: 'Markus Stumpf'; [email-masked]
Subject: Re: [Asrg] article: port 25 blocking

>We're managing only about 20-40000 domains. We have direct customers, we
have resellers. Adding useful SPF records will take *ages*:
    250 working days a year. 
    8 working hours a day
    4 domains per hour (*very* optimistic) This makes 8000 
[snip]

>Who will pay for this? With USD 5 or 6 for a domain how to do fund the
15-30 minutes it takes to query the customer for SPF records and add them?

>Reality bites.

Surely you can find an automated system for managing SPF records for those
40,000 domains you're managing.  You're already managing 40,000 MX records
right?  What would be wrong with managing SPF as well?  If you were
reinventing SMTP today, would you honestly implement it with zero domain
level authentication?

Most people already manage their own DNS when they sign up with a hosting
service via web interface.  Since they're already managing their MX records
now, no reason they can't manage their own SPF records.  There are even
automated web interface wizards that help users generate SPF records for
their DNS servers.  If a user is a clueless user that uses a brain dead
script to set up their domain, simply have the brain dead script
automatically add the SPF records in addition to the MX records.  Those
people are probably using your standard relay servers anyways so it's fairly
easy to use default settings.

George

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 13 Apr 2005 03:00:45 +0200

On Tue, Apr 12, 2005 at 04:41:28PM -0700, George Ou wrote:
> now, no reason they can't manage their own SPF records.

MX != outgoing SMTP

> There are even
> automatically add the SPF records in addition to the MX records.

Again, MX != outgoing SMTP for large parts of the Internet.
Call your provider and request a list of outgoing SMTP IP addresses and see what
you get. And remember, the IP address you use for a smart/relay may be totally
different from that the outgoing IP of that server is.

> Those

No, a not so small number of them aren't using any of our MTAs at all.

And again: changing IPs for MX servers is easy. The MX carries that name, change
the IP for that name, done. All you have to do is change ONE A record in ONE
zone.
SPF records carry IP addresses. Changing/adding/deleting the IP address of an
outgoing MTA of an ISP requires ALL zones that list (or don't yet) that IP
address in the SPF records to be changed. Even all the SPF records in domains
that are NOT under control by the ISP providing the outgoing mailservers.

Btw.
    Return-Path: <[email-masked]>
    DomainKey-Status: no signature
    Received: from smtp812.mail.sc5.yahoo.com (66.163.170.82)
      by moebius.space.net with SMTP; 12 Apr 2005 23:41:32 -0000

I can't find SPF records for netzero.com. Your mail routing is a very good
example. You send via Yahoo and you receive via mx.lax.untd.com and
mx.nyc.untd.com. Contact Yahoo and try to get a list of IPs and add SPF
records.

Don't just talk, act and add "-all" SPF records to netzero.com. (also note that
adding one for the domain is NOT enough, you have to add SPF records for all RRs
in that domain or they may be abused).

	\Maex

---

From: "George Ou" <[email-masked]>
Date: Tue, 12 Apr 2005 19:02:44 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Markus Stumpf
Sent: Tuesday, April 12, 2005 6:01 PM
To: George Ou
Cc: [email-masked]; 'Markus Stumpf'
Subject: Re: [Asrg] article: port 25 blocking

On Tue, Apr 12, 2005 at 04:41:28PM -0700, George Ou wrote:
>> Most people already manage their own DNS when they sign up with a 
>> hosting service via web interface.  Since they're already managing 
>> their MX records now, no reason they can't manage their own SPF records.

>MX != outgoing SMTP

Where did I claim "=="?  I'm simply stating that if one can manage an MX
record for incoming SMTP, then it is reasonable to ask that they manage SPF
records for outgoing SMTP.

>Again, MX != outgoing SMTP for large parts of the Internet.

Again, that's your words, not mine.

>> Those
>> people are probably using your standard relay servers anyways so it's 
>> fairly easy to use default settings.

>No, a not so small number of them aren't using any of our MTAs at all.

Then they use their own IP addresses.  What's your point?

[snip]

>I can't find SPF records for netzero.com. Your mail routing is a very
>good example. You send via Yahoo and you receive via mx.lax.untd.com
>and mx.nyc.untd.com. Contact Yahoo and try to get a list of IPs and
>add SPF records.

I have no problem changing to the official netzero.com smtp relay server
there.

George

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 13 Apr 2005 04:32:31 +0200

> SPF does all this NOT and it breaks widely deployed Internet

That's not true (a.k.a. a lie) following the spec.  Receivers
just have to check it at the one hop from the last MTA of the
sender to the first MTA (MX) of the receiver, then it "breaks"
nothing, let alone the "Internet Mail Infrastructure".

Even if a receiver screws up badly and checks it later nothing
evil happens, the MTA in question rejects the mail, and the MTA
before it creates a bounce - that strikes me as a very complex
approximation of "551 user not local", but it's SMTP as defined
in STD 10 and later.

Second attempt to break anything, somebody wants a "bounces-to"
as in mail-arch, i.e. use a given MAIL FROM anywhere.  That's
very simple, he just does not publish a sender policy, ready.

> Without > 80% of all domains deploying SPF (and SRS) I will
> never block based on SPF

That's your decision, SPF is a voluntary system, and the most
important volunteers are the spammers, not you.

> this would be a MTAMARK like list

MTAMARK and SPF are unrelated.  The only thing they might share
is the fact, that IPs marked as MTAs can be IPs of spammers,
like MAIL FROMs or HELOs resulting in a SPF PASS can be set up
by spammers.
                         Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 13 Apr 2005 05:19:31 +0200

> MX != outgoing SMTP

Actually it's "MX is not necessarily an / the outgoing SMTP".

It would be nice to have "MX == RMX", for starters it would
make SPF (the baroque form of RMX) unnecessary.  Ignoring the
"use A if no MX" loophole in this fantasy.

Maybe it was once meant this way, "Mail eXchanger" sounds like
"those who can receive can also send, and vice versa".

> the IP address you use for a smart/relay may be totally

mail2.hamburg.de != frontend-1.hamburg.de, guessing the RMX is
certainly not always trivial.  And the SPF wizard is a script,
like all scripts it's rather stupid.

> changing the IP address of an outgoing MTA of an ISP requires
> ALL zones that list (or don't yet) that IP address in the SPF
> records to be changed.

Depends.  First of all you can use a:frontend-1.hamburg.de and
then the IP can be changed without changing the sender policy.

And if you're a customer of an "SPF-aware" mail provider you'd
simply include:my.1st.mail.provider.example etc., it's then
their business to keep their SPF record up to date.

"All" foobar.claranet.de use a "v=spf1 redirect=claranet.de",
if something has to be changed it's only the latter.  That's
not precisely an optimal example, because that "all" is only
one wildcard for all vanity domains like foobar or xyzzy, but
let's say that the SPF "zone cut" idea changed twice (it will
be removed in the next draft, and it was never implemented).

> note that adding one for the domain is NOT enough, you have
> to add SPF records for all RRs in that domain

 From his POV only those FQDNs below netzero.com are relevant
that have an MX (or an A with a smtpd), e.g. mail.netzero.com
or pop.netzero.com

 From the POV of a receiver adding CSV and its "quasi-zone-cut"
could help as far as forged netzero-HELOs not covered by SPF
are concerned.  Claims that _one_ scheme, SPF / CSV / MTAMARK /
port-25-blocks / 2476-enforced-submission-rights / ... solves
_all_ spam related problems are just wrong.

                            Bye, Frank
-- 
http://www.cbronline.com/article_news.asp?guid=44D2955C-3C04-4BA1-AC45-AF8277B8B455