On Fri, Oct 10, 2003 at 06:31:01PM -0500, Bryan Campbell wrote:
adequate controls on ISP networks. Is an additional set of records
going to fix a problem that is only a problem because of inadequate
network controls on SMTP server services?
In a word, no. The root problem is not that "SMTP servers are inadequately
controlled", it is that SMTP does not provide for adequate authentication.
Are we fixing a symptom of a bigger problem? The bigger problem is lack
of accountability. For example, a properly controlled smtp queue can be
limited to only a certain number of messages per day, week, or month.
The billing ISP can bill for excess. If the content, style or type of
message is found to be spam, or viruses, then the offending account can
be charged for the excess or by violation. People respond well to
monetary motivation.
You certainly seem to have a very ISP-centric view of the world. The problem
is indeed lack of accountability, but neither you nor anyone else has
provided a reason why this means that ISPs should force all their customers
to use their smarthosts and control things at that point.
Why introduce a bad SPF when the introduction of the good SPF makes it
unnecessary? (Single Point of Failure would be a bad SPF)
Capacity, cost, reliability are all improved by distributing the SMTP load.
Well, they would be if there weren't so many idiots out there injecting
huge amounts of crap into the network.
Essentially the model you are proposing is "Big Brother", punish-the-lot-cos-
-most^Wsome-are-guilty. I most strongly disapprove.
Building something to block unauthorized relaying by SPF or SRV records
is just saying, in a more complex way, hey quit it. When you can
already tell that they are doing it by looking at your local mail queue.
~ So, what is the difference in blocking it with a protocol level service
DNS record in the transport agent or at the network level by service
type and or protocol?
You're falling for your own prejudice again. Remember that we're *not* trying
to block "unauthorized relaying" (whatever you might mean by that), we're
trying to ensure that we can know who the sender of a given email is.
Not quite sure that I follow your second sentence.
As far as blocking "at the network level by service type or protocol" goes,
who's to decide who should be authorised to run SMTP servers, then?
Maybe anyone with a class C of addresses delegated to them? Or perhaps
anyone with an ASN? Or perhaps only backbone operators?
How would your ISP like it if your upstream decided that they wanted some of
you customers, and so they'd block SMTP upstream from you except through
their smarthosts? No, that is not how the Internet is supposed to work.
There is:
a) no need to restrict who can run SMTP servers;
b) no single authority competent to decide who should be able to run SMTP
servers;
c) no way there ever could be such a central authority, as each MX operator
will have different criteria for deciding.
SPF just gives everyone running an MX a bit more information on which to
base their decisions.
Do we really need something new to regain control? Does the tool that
is necessary to fix the problem already exist?
It's not really about control (your Big Brother tendency is showing again).
It's about empowering MX operators to make good decisions about what mail
to accept. And there is currently *no* tool to authenticate the sender of
a message in such a useful way as SPF would create.
So, yes, and no.
Also, even if we do build the SPF or SRV record structures and mesh them
into the MTA checks, is it going to save us from the local users abusing
the local smtp relay server? NOPE!
If local users abuse the local server, then the local operator should be able
to tell who they are, and take local action as appropriate. If a domain
proves incapable of controlling their users, then they will be blacklisted --
on the basis of their track record, not on the type of connection they happen
to be using.
Cheers,
Nick
-------
Sender Permitted From: http://spf.pobox.com/
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/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡