[Sussex] spam filtering

[Vic]

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

You seem to have a strange definition of routing, to boot. I'd look up the
man page for the route command & see how well that fits your definition,
IIWY.

>> 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)?

You won't be able to authenticate to my MTA. As a result, you will not be
allowed to relay through my MTA. That's why your bizarre test earlier -
sending mail to my account via SMTP - proved precisely nothing. You did
not attempt to relay mail, so authentication was not required.

> Where do you publish your secret so that anyone who wants
> to send you e-mail that has never meet you can?

No-one who wants to send me email needs to authenticate against my MTA.

Anyone who wants to relay through my MTA does need to authenticate.

Anyone who needs to authenticate to my MTA already knows how to.

You are not among that group.

You will not be able to relay through my MTA

That does not preclude you sending email to a domain served by my MTA.

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

That's a welcome, but incidental effect.

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

OK, A a significant portion of what you are saying is completely wrong. So
rather than tell me how life is, why don't you learn a bit before shouting
your mouth off? You have made some severe and fundamental errors in what
you've said - specifically, your incomprehension of relaying and your
incorrect reading of the SPF records we have discussed. Get your knowledge
together and you'll realise why you are now wasting everyone's time.

A few hours' reading of specs does not an expert make.

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

You have read the meaning of the modifier attached to the default clause.
You have applied it to the entire record. This is wrong. Each clause in
the record has its own modifier (optionally omitted, in which case a "+"
is assumed).

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

I don't have to accept anything I don't want to. It's my MTA, and common
laws of property tell me I can do what I like with it.

What SPF does is to tell me that certain messages are not forged. That
might well influence my decision to accept something, but it in no way
requires me to accept a message I know to be spam. If I want to reject a
spammy message from a non-forged source, that's my right, and I'll
continue to do so.

If, however, I detect a forged message, I can choose to reject the
connection before the DATA phase has even started. That is in addition to,
not in place of, any other filtering I choose to do.

>> Absolute rubbish. MSAs use port 587.
>
> You don't understand how e-mail is sent.

Well, one of us doesn't. How many MTAs have you set up that use the MSA port?

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

Got this bit? "Messages received on this port are defined to be
submissions". 587 is for submissions only; it's where you put the
authenticated traffic. It's not blocked by any ISPs of which I'm aware
outside China. The bit you've just quoted defines what I've been talking
about. Now let's address your port 25 stuff :

>        A site MAY choose to use port 25 for message submission,
>        by designating some hosts to be MSAs and others to be MTAs.

Note the "MAY". That means it can, or it could not - depending on the
choice of the person who set it up.

Now you might choose to allow submission on port 25 . This gives you all
sorts of problems with port 25 blocking, but can make life easier at
times. *However*, if your MTA accepts submissions for relaying without
authentication on this port, you are an open relay, and you will end up on
more blocklists than you can imagine, due to the volume of spam you will
soon be relaying.

So whether you run MSA on port 25, port 587, or both - you *still* need to
run authentication before allowing relaying. The major advantage of 587
over 25 is that 587 doesn't get blocked - and won't either, as this suits
the ISPs down to the ground.

> 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

Why would they do that?

ISPs don't block port 25 because they *want* to provide lots of compute
power to run everyone's email. They do it because, if they don't, SMTP
engines get set up running shedloads of spam through that conduit.

MSA spam doesn't happen. Can't happen. If someone attaches to port 587,
they are *required* (in all sane configurations) to authenticate straight
away. Can't authenticate? Then don't send your email through this
connection - byeeee. No spam.

So ISPs gladly allow port 587 - it does the anti-spam job required of them
and it costs them nothing in return. Profit margins all round!

> and that would break using both SPF and a vanity domain.

It would not break SPF. SPF doesn't care how you get mail into the
submission chain. All it cares about is that the MTA that eventually
connects to the MX dosen't forge the envelope.

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

"the only outbound SMTP route allowed is via their ISP" is not true.
Whilst their ISP might not permit port 25 SMTP traffic, it will allow port
587 ESMTP. See that phrase "the only outbound SMTP route" that you used?
It's wrong.

> C   MAIL FROM: steve at dobson.org

Note that dobson.org does not have an SPF record. So even if the MX you
used had an SPF filter on it (it doesn't), this would not rate a SPF
rejection.

> C   RCPT TO: lug at beer.org.uk

This is a local address. There is no relaying involved, so authentication
is not required.

> C   QUIT
>
> S   221 2.0.0 hobgoblin.beer.org.uk closing connection

OK, 10/10 for documenting a simple SMTP transaction. But minus several
million for producing anything relevant.

You have not attempted to relay anything, so this is not pertinent to
anything we've discussed about authentication. You have acted as an MTA,
not an MSA.

Furthermore, you have not attempted to forge an email, and not done so via
an MX that doesn't run SPF filters anyway.

In all, your little experiment really was a waste of time.

> Now while my message wan't SPAM (as in unsolicited bulk email) it could
> have been

Oh for crying out loud, how many more times.

SPF IS NOT ABOUT REJECTING SPAM. SPF IS ABOUT REJECTING FORGERIES.

Until and unless you understand the above, it is pointless continuing this
argument whatsoever. SPF is not about rejecting spam, it's about rejecting
forgeries. Don't wuote the pobox.com website back at me - we all know what
it says there, and we all know that's wrong, but they won't change it.
You'll see I mentioned that much earlier in the thread. Oh - and SPF is
not about rejecting spam, it's about rejecting forgeries.

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

Yes, they could have sent me any email for which this machine is the MX.
That says nothing whatsoever about SPF, and nothing whatsoever about
relaying or authentication.

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

Why?

MX is how you receive email. It says nothing *whatsoever* about how you
send email.

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

That's complete rubbish.

The MX record does not say anything whatsoever about how email is sent. It
does *NOT* tell anyone that "mail is handled by marvin not taz". It tells
people to connect to marvin when sending email *TO* the domain - and
that's *ALL* it says.

Vic.