From: Michael Elliott
Date: 2005-07-06 18:41:15 -0400
Subject: Re: New milter-spiff : A SPF-Classic implementation.
More information..: http://www.milter.info/#Support
Anthony Howe wrote:
> Michael Elliott wrote:
> >>Sendmail supports a DISCARD in the access.db and as a milter action. I
> >>personally never use that prefering rejection or tagging. Yes. People
> >>can shoot themselve in the foot with any discard option, but there will
> >>always be someone who wants that flexibity to decide and experiment.
> > As a selective match. You are suggesting using it as a default case.
> Huh? Where? I make no such recommendation. For -H and -M there is text like:
> A reasonable setting might be -H softfail-tag,fail-reject.
> No mention of using either *-discard choices. The default action for
> BOTH -H and -M is simply adding Received-SPF: headers with no action
> taken, not even tagging.
Ok. I screwed up there. I was trying to say that
A) if there is an option available that does not have a "warning dangerous"
attached to it, users will try/use it. 50% of users don't read the
manual. Even less read the spec. They type make, and it it doesn't
complain, they add it in. An example. A customer really did this.
And then wondered why they were blacklisted for being an open relay.
B) DISCARD in sendmail is used in the access.db as a selective match to
a domain, sender, receiver, or ip address. Your option, if it is used,
will discard the mail on ALL fails or softfails as the option specifies.
That is where my "default case" slipped in.
I know you want to give the sysadmin all the options possible. Marking
the *-discard options with safety orange or red is what I am asking for
because I see too many sysadmins without sufficient clue to distinguish
the dangerous options on their own.
> > Please just add some red text that using discard is not advised because
> > the mail disappears into a blackhole without sender or receiver's knowledge.
> > It should only be used on known bad spammers/viruses.
> >>Thats a local policy choice.
> >>RFC 2821 states the DSN null address must be accepted and there are
> >>clear reasons why, but people still choose to block MAIL FROM:<> for
> >>local policy reasons, which I'm very very much against. I however had to
> >>finally conceed that there will be sites that think blocking <> is
> >>clever and so implemented MxCallBackDsnBlocked in milter-sender as a
> >>means to fall-back on the grey-listing.
> > Again, add some warning text that softfail reject is against the domain
> > owner's wishes and will cause legitimate email to die.
> I could, but users should be reading the Internet draft documents how to
> specify their SPF records and understanding what SPF is about.
50% won't read beyond the web page or the man page. And, the easier it
is to install your packages, the higher that number will climb.
> A ~all leaves your domain(s) still open to spammer sender forgery and is
> next to useless only by nanometers. Essentially by publishing an SPF
> record with an ~all final choice, you've caused a pile of extra DNS
> lookups (at least extra per a, ptr, mx, include, exists, and/or redirect
> mechanism used), might have said where things do come from for certain,
> and then bail at the very last by stating ~all. Essentially ~all is no
> better than if you had no SPF records at all.
Wrong. Hotmail.com is a perfect example. It lists all their mail
servers that the mail is supposed to come from, and anyone using
their servers will get a PASS correctly. But, anyone can use a
hotmail.com email address because it was designed as a mail destination
service. Hotmail doesn't provide the dialin or dsl to get you to
their service. They never have. So, their records state
These are our mail servers, and anything else may be legitimate
so use another filtering method to check any non-pass condition.
On a system that tries to minimize DNS traffic/cpu cycles it would
be possible to do the equivalent of:
milter-gris passes, milter-spiff gets a PASS, skip milter-sender
with some accuracy sacrificed for cpu cycles.
milter-gris passes, milter-spiff gets a SOFTFAIL, check milter-sender
and hotmail.com will tell you if they are a valid user or not.
Under your system and most systems, all checks are tried every time.
The order of the milters is what determines which milter has the first
chance to reject a message. Since milter-sender is more cpu intensive
it should normally be at the end of the list, giving the others a chance
to reject the mail first by easier means.
> As I recall ~all is a migration & testing path setting. Domain owners
> can state what they know and/or testing under SPF, but ~all is their
> recommendation. Its an inbound postmaster's choice to honour that or
> impose stricter choices as they see fit. That is why my suggested
> settings for -H and -M are :
> -M softfail-tag,fail-reject
> which reflects the SPF spec. recommendations.
I wanted it clearly stated that the stonger options of softfail-reject
is going beyond the spec and the domain owner's choice. The ~all says
to use another method to check, not "you are free to keep or reject
based on personal choice". Yes, a sysadmin can always do what he wants,
but if the dividing line is allowed to move so freely, the spec itself
Domains above 100,000 users will never be able to go to a -all record.
But, there are probably less than 10,000 of those domains. For the
other millions of domains that have less than 100 users, a -all is
possible. Both small and large domains have to use ?all and then
~all as their confidence increases. I am trying to keep the dividing
line from getting fuzzy.
> And since many spammers use SPF records, in and of itself is not an
> anti-spam tool as originally conceived. SPF is an anti-philishing tool.
It was always an anti-forgery tool. My logs show its sucesses as
95% anti-virus, 4% anti-forgery, and 1% anti-phishing.
> I wrote a length USENIX/SAGE ;login: article on anti-spam that came out
> last month where I discussed this and other methods.
> Anthony C Howe +33 6 11 89 73 78
> http://www.snert.com/ ICQ:
7116561 AIM: Sir Wumpus
> Sendmail Anti-Spam Solutions http://www.snertsoft.com/
> We Serve Your Server
Copyright 2009, 2012 by SnertSoft. All rights reserved.