TMDA Re: [Gllug] New worm doing the rounds?

[Bruce Richardson]

On Tue, Feb 17, 2004 at 05:51:03PM +0000, Jason wrote:
> >  If SPF were widespread, I'd have
> > another incentive to set things up properly.  In fact, SPF would make it
> > easier for me to be official, given that I have a fixed ip address,
> > because I could ask UKLinux to add SPF records sanctioning the use of my
> > ip address for my domain.  That way I could send mail from my personal
> > domain directly, but if I wanted to send mail from @uklinux.net, I'd
> > need to send my mail via the uklinux mail servers.
> 
> Thus you loose the freedom to use your uklinux email address except when 
> using their mail servers.

Not if they use a wildcard record.

> Wildcards records would quickly become the norm for most email addresses 
> thus totally undermining the scheme.

They might become the norm for ISPs but are you seriously saying that
they would become the norm for all the businesses and private
organisations that own e-mail domains?  I seriously doubt it.   So no
undermining, in fact.  Not only that, but I'd be surprised if every ISP
did wildcard records.  Some already do SMTP filtering and others who
don't because of the associated technical 
 
> > Of course, mail administrators like
> > myself would probably add special policies to deal with domains that had
> > wildcard records but then that is my right.  Nobody has an inalienable
> > right to send me e-mail and have it accepted.  Anybody who thinks they
> > do can apply personally for a thumping.
> 
> This is true however when you think this way remember that you are 
> encouraging the splintering of the net

No, I am not.  Try and make specific arguments rather than straw-man
smears.

> and reducing the number of 
> recipients who will be likely to accept your own legitimate email.

Perhaps you could provide some evidence for that.  Like, any reason at
all.

> 
> > At the moment, you can abuse the Internet mail system to send mail using
> > my personal domain in your headers.  Now, the fact that you are
> > technically able to do that does not make it a right and the imposition
> > of technical obstacles to prevent you from doing that is not the removal
> > of a right.
> 
> You know full well that I never suggested any such "right". 
> 
> You should also know that no scheme to try and impose controls can work 
> without fundementally undermining the function of email as a positive and 
> easy to use communication method.

You keep saying things like that without any proof.  RBLs haven't done
that, even though they are a much inferior mechanism.  The simple fact
is, most people with ISP e-mail accounts have the default set-up that
came with the installation CD or .ins file, and those default settings
route their mail through their ISP's mail relays.  So they wouldn't feel
the slightest impact from SPF, except that they would start receiving
less spam.

> 
> > > It's another non starter for anyone who values the freedom of separating 
> > > their email address from their current connection etc.
> > 
> > No, it isn't.  There are always ways, as I've outlined.
> 
> The ways you've outlined are unworkable in my view. My views are not 
> entirely without a basis in solid experience.

Just saying that won't wash with me because I'm an experienced mail
administrator myself.  It's not an argument, it's a posture.

> 
> > > Note from the obstinate: if can only be effective if you take away 
> > > significant freedoms from 'net users and impose "single supplier" limits 
> > > that are unlikely to be attractive to users.
> > 
> > No.  Sorry, just no.  The option of wildcard records makes that just so
> > much huge, hairy bollocks.  Any Internet organisation that thinks it is
> > defending basic freedoms can have wildcard records.
> 
> Which as you have already stated will probably be administratively 
> punished by others resulting in people only being able to use email where 
> the single supplier lock in is in place.

Actually, if you look at what I wrote, I illustrated that I would simply
apply more stringent spam checks to organisations with wildcard records,
than to those without.  That's not the same as a lockout.  In fact, I
could treat SPF-wildcard domains exactly the same as any other domains
with valid SPF records and still win, because I'd still be eliminating a
huge amount of spam by just rejecting the mail that violated SPF.

> 
> > It's also a much better way of allowing mail administrators to choose
> > policy than RBLs, because it lets me base my mail policies on the
> > information that *you* provide, rather than the prejudices of some rbl
> > maintainer. 
> 
> And how do you know you can trust *me*? Do you expect spammers not to 
> publish their own misleading SPF records? They already publish misleading 
> DNS records and otherwise seek to mislead though the use of protocol 
> abuse.

You know perfectly well that spammers send most of their mail by
abusing other people's mail systems.  Spammers who use their own domains
are easily traced and added to rbl lists.  In an Internet using SPF or
an equivalent, rbl lists that only listed domains that belonged directly
to spammers would be practical and useful tools.

Besides, how could they publish *misleading* SPF records?  You can't
publish SPF records for other people's domains.

> 
> > In a world where SPF or some similar system had had gained
> > hold, I could, off the top of my head, classify mail in 3 broad
> > categories:
> > 
> > 1.  Mail whose source and headers match the associated SPF records (from
> > a domain that doesn't have wildcard SPF records).
> > 2.  Mail whose headers and source do not match in violation of the SPF
> > records for the sender domain.
> > 3.  Mail whose headers match an SPF wildcard.
> 
> If that's the only classification open to you all you have is a very blunt 
> tool.

Rubbish.  I can apply sophisticated policies to each group.  The bonus
is, that I can apply *different* policies to each group.  If SPF were an
established part of the Internet architecture, I could reject mail in
category 2 absolutely, with no further checks.

> > There are proposed migration paths, both for this and for other schemes.
> > Even if only a few 
> 
> I remain unconvinced.

Again, that's a posture, not an argument.

> I disagree. It's too blunt an instrument to offer any real balance and it 
> looks far to trivially easy to abuse.

Neither of which you have backed up.

> 
> > Mail systems all over the world reject all kinds of mail for all kinds
> > of reasons.  As long as they give a valid smtp response or NDR, they are
> > doing absolutely nothing wrong.  The problem at the moment is that the
> > abuses of the current technology are panicking many organisations into
> > imposing policies that are arbitrary and unfair.  SPF or something
> > similar could do a lot to stop that.
> 
> No it wont. You've admitted in your own message that it's insufficient on 
> it's own 

You're twisting my words.  I said it could provide the basis for
policies.  The fact that I would build upon it doesn't make it a poor
foundation.

> and you still need additional policies and systems to retain 
> control over your email.

The current Internet architecture is failing its users.  Systems that
were designed to deal with a small and accountable community can't cope
now that half the world is online.  SPF (or a similar scheme) would just
one incremental improvement in the architecture.  The fact that it would
not be the only needed change doesn't make it a bad change.  Incremental
change is generally the best way to move if you want the system to
remain stable.

If incremental improvements to the architecture of the Internet are not
made, companies like Microsoft will use the opportunity to put in stupid
user-space solutions that make people more dependent on their software.

-- 
Bruce

Remember you're a Womble.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: Digital signature
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20040218/8f561b0e/attachment.pgp>
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug