[Sussex] spam filtering

[Steven Dobson]

Vic

On Sun, 2006-08-20 at 02:12 +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's about whether or not to accept an SMTP connection. Routing is neither
> here nor there.

Oh come on!  SPF checking is suppose to be done by MTAs.  Programs like
sendmail or exim.  The _only_ job of a MTA is to route e-mail!
Therefore this IS a routing problem.

> > 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".
> 
> That's what SMTP-AUTH does. And that's got nothing whatsoever to do with SPF.

SMTP-AUTH uses some kind of shared secret.  You and I haven't exchanged
secrets so how does my MTA (exim4) authenticate itself to your MTA
(sendmail)?  Where do you publish your secret so that anyone who wants
to send you e-mail that has never meet you can?

> > So how much SPAM does this block for you?
> 
> SPF is not about blocking spam. SPF is about preventing forgery.
> 
> How much forgery does this block for me? I used to get tens of bounces
> every day because one of my domains was getting forged. In the couple of
> years since I posted an SPF record, I have had *one* forgery. I'd say
> that's effective.

Which will block a lot of SPAM because some SPAM is forging the senders
domain.

> > 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?
> 
> You appear to have some strange ideas about what SPF does...

No doubt.  I have only what you've said and what I've read in the last
few hours - since the start of this thread.

> > Of the five examples I've looked at and understood _none_ are protecting
> > themselves.
> 
> Then you've not understood what is going on.
> 
> > 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.
> 
> That's exactly wrong. The SOFTFAIL result does not mean that at all.
> 
> > 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".
> 
> Do you think that means that the record is synonymous with a null record?
> If so, you've misunderstood SPF again.

The quote "MUST be treated exactly like the `None' result" I lifted from
the SPF spec.  If it doesn't mean what it says then what does it mean?

> > 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.
> 
> That is the choice they make. As you can see from the records posted by
> both Hotmail and Gmail, they are already preferring traffic to be sent via
> their MTAs. It is down to them whether or not they require that.

WHICH IS MY POINT!  If someone is allowed by the domain's SPF record to
send out an e-mail with a return path for that domain then your MTA
(sendmail) have to accept it because the domain said you should.

> >   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.
> 
> Absolute rubbish. MSAs use port 587.

You don't understand how e-mail is sent.  Here is the definition of an
MSA.  Here is the defintion from RFC 2476

    Message Submission Agent (MSA)

      A process which conforms to this specification, which acts as a
      submission server to accept messages from MUAs, and either delivers
      them or acts as an SMTP client to relay them to an MTA.

And here is a section that says while port 587 CAN be used so can port
25.

    3.  Message Submission

    3.1.  Submission Identification

       Port 587 is reserved for email message submission as specified in
       this document.  Messages received on this port are defined to be
       submissions.  The protocol used is ESMTP [SMTP-MTA, ESMTP], with
       additional restrictions as specified here.

       While most email clients and servers can be configured to use port
       587 instead of 25, there are cases where this is not possible or
       convenient.  A site MAY choose to use port 25 for message submission,
       by designating some hosts to be MSAs and others to be MTAs.

And even if the world did move over to using port 587 ISPs can block
that port too and then their clients can only send e-mail via the ISP's
own e-mail systems - and that would break using both SPF and a vanity
domain.

> >       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.
> 
> That's inbound traffic. It's completely separate from outbound.

Agreed

> >       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.
> 
> Still wrong. MSA port is 587.

Wrong - see above.

> > 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.
>
> I have no idea what that means.

Okay I'll explain it.

Here is how to send an e-mail using telnet to connect to port 25.  I
used your server so you should have got the email.  Lines prefixed with
a "C" where typed my me as the client, and lines prefixed with an "S"
where issued by your MTA sendmail.

    $ telent beer.org.uk 25 

S   220 hobgoblin.beer.org.uk ESMTP Sendmail 8.12.11.20060308/8.12.11;
       Sun, 20 Aug 2006 07:09:39 +0100

C   HELO syscall.org.uk

S   250 hobgoblin.beer.org.uk Hello taz.syscall.org.uk [82.68.142.129],
       pleased to meet you

C   MAIL FROM: steve at dobson.org

S   250 2.1.0 steve at dobson.org... Sender ok

C   RCPT TO: lug at beer.org.uk

S   250 2.1.5 lug at beer.org.uk... Recipient ok

C   DATA

S   354 Enter mail, end with "." on a line by itself

C   Subject: A test message using telnet
    This is just a quick test to show how a SPAMMER could send you
    an email using telnet.
    .

S   250 2.0.0 k7K69dif015732 Message accepted for delivery

C   QUIT

S   221 2.0.0 hobgoblin.beer.org.uk closing connection

    $

Note the line from your server which identify the machine that connected
to it as taz.syscall.org.uk [82.68.142.129].  Your MTA has done a
reverse DBS look up on the IP address of the client (82.68.142.129) and
found that it is identified as "taz.syscall.org.uk".  This is my
firewall.  The machine I am using to make the telnet connection
(roadrunner) is one of the machines on my LAN.

Now while my message wan't SPAM (as in unsolicited bulk email) it could
have been - anyone can connect to your SMTP port on your e-mail server.
They have to.  That's how e-mail is transfered about the net.

Your MTA could have gone further in checking that the connection machine
was ligitimate in sending e-mail.  It could check the MX records for
taz.syscall.org.uk.

   $ dig taz.syscall.org.uk mx
   ;; QUESTION SECTION:
   ;taz.syscall.org.uk.         IN MX

   ;; ANSWER SECTION:
   taz.syscall.org.uk.    86400 IN MX 100 marvin.syscall.org.uk.

   ;; ADDITIONAL SECTION:
   marvin.syscall.org.uk. 86400 IN A      82.68.142.130

From this you can learn that the mail is handled by marvin not taz and
as the connection came from taz it is not the licensed e-mail server for
the syscall.org.uk domain.

Now before everyone jumps on this trick it doesn't work for two reasons:

1). Not all e-mail systems have been configured with MX records.

2). For large networks the e-mail senders are not the same machines that
receive.

Steve


-------------- 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/20060820/c9fb20a9/attachment.pgp