[Mimedefang] Process SPF checking for certain recipient domains

[G.W. Haywood]

Hello again,

On Fri, 25 Jul 2014, Jon Rowlan wrote:

> The problem is that some domains that I host on my mail server I
> want a harsher protection than others.

That's not a problem, it's a requirement.  Almost everybody does it.

> In this particular case, a certain set of recipients have received
> bombardments of email from a set of IP's and they complain about two
> or three hundred emails in a day coming into their mail box.

Two or three hundred spam mails in a day isn't really a bombardment.
Several hundred thousand might be called a bombardment.  At my own
business, the most we've seen in one day is about seventy thousand.
All rejected of course.  Once you see the rejection rates rising in
the logs (you keep a weather eye on your logs, don't you?) then for
example something like

/sbin/iptables -A FORWARD -j LOG_DROP -s spammy.IP.addr.ess

in the firewall stops them even connecting, with very little fuss and
no complicated Perl scripts.  I don't see what SPF has to do with it.

> They would suffer the consequences of an SPF protected mail server

What consequences?

> (innocent senders are blocked because they don't use SPF

That's nonsense.  Go read the RFCs, understand what SPF is about.
If a sender doesn't use SPF then the receiving mail server takes
no action as a result.  At least that's what's supposed to happen
in a properly configured server.

> and mail bounces)

You do know the difference between a mail rejection and a bounce?

> because they would see less spam,

SPF is about forgery of mail, not about spam.  Granted, forged mail
is often spam, but there's a clear distinction.

> whereas other clients want to see all email

# Tryhing to stay vaguely on-topic, as this is the MIMEDefang list :)
sub filter_recipient
{
   my ($recipient, $sender, $ip, $hostname, $first, $helo,
       $rcpt_mailer, $rcpt_host, $rcpt_addr) = @_;
   if ($recipient =~ /^<?spamlover\@example\.com>?$/i)
   {
     return ('ACCEPT_AND_NO_MORE_FILTERING', "ok");
   }
   return ('CONTINUE', "ok");
}

... but I probably wouldn't do it that way.

> and will not tolerate too many bounces from their clients.

I didn't follow that part.

> I want to selectively use SPF for some domains and not others for
> the purposes of the functionality that SPF offers. I want to tune
> this depending on the client domain.

Assuming that it's implemented properly, SPF tells you if a mail is
forged.  For some meaning of the word 'forged'.  Nobody wants forged
mail, so there's no reason to implement SPF for only some of your
clients.  But to be perfectly honest, at present (after all SPF has
only been with us for about a decade) so few people publish sane SPF
records that you might as well simply not bother with it at all.
Really.  Put your efffort into something that will yield some return.

The vast majority of SPF records that I see have been cobbled together
using some bug-riddled WebWizard by incompetents who have no idea of
what SPF is for, nor how it works.  Once they've set up the faulty SPF
record they seem to be either terrified or incapable of doing anything
to it - such as fixing it so it doesn't cause more trouble than it's
intended to prevent.  Customers of these incompetents then start going
round in small circles and yelling that we've rejected their mail when
it's their provider's policy that said we should do so.  Go figure.

The best thing you can do is forget you ever heard of SPF and do some
reading on mail protocols so that you understand what you're doing,
which clearly you do not at the moment.

>> Stop digging.
> 
> Digging for what? Answers, I thought that was the point of asking?

I meant stop digging that hole.  Clarify the issues before you go off
solving problems of your own making.  You might want to run the SPF
record for sads.com past the people on the spf-help mailing list:

spf-help at listbox.com

--

73,
Ged.