SPF

[Alex Neuman]

Ok... So would a conservative-yet-effective approach be:

1. Sendmail gets message, checks SPF. If SPF records say mail came from
unauthorized server, drop the connection. If no SPF available, receive
e-mail anyways (for now).
2. MailScanner gets message from Sendmail, passes message to SpamAssassin
for processing. SpamAssassin checks SPF records, assign arbitrary negative
number (say, -2.0) if SPF records check out ok, otherwise process as usual.

Less conservative efforts would range from harsh (assign positive score to
non-SPF messages when checked by SA) to brutal (drop non-SPF messages at MTA
level).

Is my understanding correct? Has anybody who's already implemented SPF at
the MTA level using RPM-installed sendmail worked out something like this,
and if so, where did you find info on it?

Thanks...

-----Original Message-----
From: MailScanner mailing list [mailto:MAILSCANNER at JISCMAIL.AC.UK] On Behalf
Of William Burns
Sent: Tuesday, August 10, 2004 12:42 PM
To: MAILSCANNER at JISCMAIL.AC.UK
Subject: Re: SPF

John:

SPF in your MTA blocks mail from IPs that don't belong to a senders
domain. (if SPF is configured for that domain)
Once mail is accepted, having SPF in your anti-spam system provides a
higher confidence that mail from a senders domain is not spam. (again,
if SPF is configured for that domain)
MailScanner is kinda' in-between these two things. The only reason to do
SPF in MailScanner is if it is not supported in your MTA.

The MTA (Sendmail) is the first line of defense.
If you've got SPF there, then mail won't be accepted in the first place,
so MailScanner will never see it to do any processing.

If SPF is not done in the MTA, but done in MailScanner (or in Spam
Assassin) then there's a chance for MailScanner to archive the mail
based on "failing" SPF.

It seems to me, that if SPF is configured for a certain domain, you
should trust it completely, because the senders domain is trusting their
mail services to SPF.
For that reason, you should (at least) implement SPF in the MTA. Having
Mailscanner archive mail that fails SPF is not helpful 'cause you
already know that this mail is garbage.
The only reason to avoid using SPF in the MTA is if you do not trust the
admins of the sending domains to configure SPF properly. But that seems
kinda' paranoid to me.

If you're already doing SPF in the MTA, it's still useful to do SPF in
Spam Assassin 'cause Spam Assassin would know that it was less likely to
find spam coming from domains that had SPF configured.

Does that make sense?

-Bill


John Hinton wrote:

> One of the beauties of SPF as I 'sort of' understand it, is the DNS
> record is checked first and only if it passes is the server opened to
> receive that email (seems like MailScanner is the front line and that
> would be the place to do this?). I'm not sure about exactly what happens
> and when, with MailScanner, but I would like to know that the first
> check made is at the DNS level and only then receive the email and put
> it through whatever paces are in place, AV, AS and so forth. This would
> be a huge reduction in server loads. Why do all that processing if only
> then at the MTA level, does the email get rejected (server refuses to
> download it)?
>
> Would this be the case with the current MailScanner? I am running RHEL
> and sendmail. I will be adding the SPF sendmail patch at an appropriate
> time.
>
> Best,
> John Hinton
>

-------------------------- MailScanner list ----------------------
To leave, send    leave mailscanner    to jiscmail at jiscmail.ac.uk
Before posting, please see the Most Asked Questions at
http://www.mailscanner.biz/maq/     and the archives at
http://www.jiscmail.ac.uk/lists/mailscanner.html

-------------------------- MailScanner list ----------------------
To leave, send    leave mailscanner    to jiscmail at jiscmail.ac.uk
Before posting, please see the Most Asked Questions at
http://www.mailscanner.biz/maq/     and the archives at
http://www.jiscmail.ac.uk/lists/mailscanner.html