[Sussex] spam filtering

[Steven Dobson]

Vic

On Sat, 2006-08-19 at 14:58 +0100, Vic wrote:
> > This is only done at
> > domian level - so as any big e-mail portal like NetIdentity, GMail or
> > HotMail would have to allow _all_ ISPs to route their domains as they
> > are bound to have at least one customer with every ISP.
> 
> It's nothing to do with routing.

What is it to do with then?  It is the task of the MSA to send e-mail on
to another MTA.  But that MTA may only be one hop in many to get the
e-mail where is needs to go.

> What most mail providers do is to provide an SMTP-AUTH service. That way,
> the end-user sends mail to the MSA, which is then sent on from the known
> (and SPF-declared) MTAs.

So in your SPF controlled world you would have all MUAs connect to the
email servers of the sender's domain.  So how do you authenticate me
when my laptop is plugged in to some random Starbuck's WiFi network?  I
would still like to send e-mail as "me".

> Note that, of the three domains you mentioned above, only NetIdentity take
> this approach. Both Hotmail and Gmail publish SPF records.

So how much SPAM does this block for you?  mailman.lug.org.uk &
lug.org.uk have not specified SPF records and the send's address is not
the same as the envelope's.  How do you let those in?

> > SPF's only work for some e-mail configurations, not all.
> 
> SPF can work for any configuration. It just happens that some domains
> *choose* not to protect themselves against forgery. That's their right,
> and they must accept the consequences.

Of the five examples I've looked at and understood _none_ are protecting
themselves.  beer.org.uk & hotmail.com both have a "~all" (softfail)
terminator which tells me that the domain owner can not guarantee that
all ligitimate e-mail that claim to come from their domain do.

As for GMail it has a redirect to _spf.google.mail and that has a list
of IP servers and then defaults to "neutral" which, from the spec, "MUST
be treated exactly like the `None' result".

I can see how businesses and power home users (like you and me) can
configure their MUAs & MSAs correctly.  Only then can they publish SPF
records that let all other MTAs know that if the sender's address
doesn't come from their domain's e-mail server then it IS spam.

But where SPFs fail is were people use e-mail addresses that are not
local to the domains from which they send their e-mail.  E-mail service
providers, like HotMail, GMail, and Yahoo, can not afford to lock down
their SPFs because:

  1). That would force all their customers to only send email via the 
      e-mail services providers servers.  This would increase the 
      bandwidth those companies needed and that has to be paid for by
      someone.

  2). Anyone that uses an ISP that blocks outbound port 25 connection
      (forcing all outbound e-mails to go via the ISP's mail servers)
      could not also be a user of a e-mail service provider unless they
      just used a web frontend.

      Most people I've see that have such an account much prefere to
      just point their MUA's POP3 or IMAP client at the server.
      While this is fine for reading e-mails they couldn't send because
      the only outbound SMTP route allowed is via their ISP - and any
      e-mails send that route would be block by the receiver's MYA.


And on Sat, 2006-08-19 at 17:47 +0100, Vic wrote: 
> > Very few people currently consider direct-to-MX from a dynamic IP as a
> > legitimate way to send email. I count myself among that number.
> 
> That was less than clear, wasn't it?

Well we all suffer from that from time to time.

> What I meant was that I consider direct-to-MX from a dynamic IP as grounds
> for rejecting the connection.

I would go futher and say that if the connecting MTA is not configured to 
be a MTA at all then you can reject anything it send.  

Steve

P.S.  I concider it polit to attribute the person when you quote them in
your replys.  I helps me go back and read the whole e-mail if I don't get
enough from the quote.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mailman.lug.org.uk/pipermail/sussex/attachments/20060819/3d6e892d/attachment.pgp