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

Bruce Richardson itsbruce at
Tue Feb 17 15:43:49 UTC 2004

On Tue, Feb 17, 2004 at 12:08:15PM +0000, Jason wrote:
> On Tue, 17 Feb 2004, Bruce Richardson wrote:
> > SPF isn't a challenge/response mechanism.  It's a suggested extension to
> > current DNS practice that would allow organisations to specify which
> > mail systems are allowed to send mail for their domain (current practice
> > only allows you to specify which machines will receive mail for your
> > domain).  If such practice were widespread, it would enable mail admins
> > to reject any mail with an address if it didn't come from a
> > designated sender machine woth out even looking any further.
> And your own email is proof of the fundemental failing in the SPF scheme.

No, it isn't.  I own my own domain.  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, I'd
need to send my mail via the uklinux mail servers.

> You are clearly authorised to use your email address and to send out email 
> from that domain to do so. It's not reasonable to impose a limit 
> preventing you from using your email address to send email except through 
> your ISPs mail server.

Why not?  If I could impose that limit for our work domain, I'd do it so
quickly it'd happen yesterday.  If, otoh, UKLinux or any other
organisation wanted to allow anybody to mail from anywhere,
they could have a wildcard record.  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.

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.

> 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.

> > Note for the obstinate: like many other mail policies, SPF would only be
> > effective for an organisation if the policy were applied on *all* mail
> > exchangers, "backup" or no.
> 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.

SPF is just a way of providing information, not forcing restrictions.
It allows mail administrators to set policy, it doesn't force that same
policy on everyone.  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.  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.

Now, categories 1 and 2 give me obvious choices.  With category 3, on
the other hand, I have a range of options that I can apply with some
discrimination.  I could decide to accept no mail from those domains, I
could accept mail only from their mx hosts, I could decide that I admire
their principles and accept all mail claiming to be from their domain.

In practice, I'd run it all through spamfilters, anyway, but SPF would
allow me to reject much more invalid mail before that.  The difference
would be that mail allegedly from your wildcard organisation would be
generating far more spurios NDRs and causing a nuisance for your
legitimate users.

> As a result it's unlikely to be taken up widely so those who do become 
> early adopters will be causing problems for everyone else.

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

> It's rather akin to having a local neighbourhood barricade itself off and 
> insist that only those personally known to their employed guards can enter 
> to make deliveries, etc. Very soon such a neighbourhood will find itself 
> without any deliveries while also causing disruption to those nearby.

Again, huge, steaming, hairy bollocks, for all the reasons outlined
above.  SPF would allow me to reject more invalid (by my designation)
mail outright while running other mail through the usual checks.  I try
quite hard to strike a balance there, since we have contacts worldwide
and our staff expect to be contactable not only by them but anybody else
with a legitimate purpose.  SPF would let me strike this balance more
scrupulously, with less error.

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.


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: <>
-------------- next part --------------
Gllug mailing list  -  Gllug at

More information about the GLLUG mailing list