Peter J. Holzer wrote:
In our implementation, we use CBV (Callback Verification) and this
resolves at least 50%, 70% to even has high as 90% of the "bad" MAIL
FROM: problem. Currently it is among the highest filter in our suite of
SMTP filters.
Apart from other objections agains CBV, this only removes those cases
which were mostly harmless in the first place: If the forged sender
doesn't exist, the NDN cannot be delivered and will be silently
discarded (or sent to a local "double bounce" address where they will
probably be ignored ;-)). If the forged sender *does* exist, CBV won't
detect that it is forged and an NDN may be sent to the hapless victim of
the forgery.
But pete, we don't want to accept mail, create bounces and a create
larger outgoing queue overhead than necessary. The whole point is to
reduced payload transfers, acceptance and bounce overheads, even it
they will quickly fail. If you don't have to send a bounce, why do it?
SPF, DKIM, BATV, etc. do a better job guarding against
address forgery.
Can't comment about BATV.
IMV, DKIM is pretty useless without some sort of domain protection
technology wrapper such as policy, unless the suggestion is that a
DKIM validation sans policy failure has a payoff? Current DKIM mail
capturing shows a pretty high volume of spammers.
SPF, +1, works great iff the site is using a hard failure policy.
Relaxed policy is wasted overhead, what value does a "Maybe, I don't
know." result have? Why bother? Relaxed provision in these protocols
just add to confusion, ambiguity, derivatives, and add receiver
overhead waste, solves nothing.
But I do see many soft/neutral SPF results rejected by a follow up
CBV. :) Let me see if I can find one in today's log...., just within
the hour:
20100813 13:01:07 testorder : FLT RBL SPF CEP CBV
20100813 13:01:11 sapfilter : pass (time:4406)
20100813 13:01:11 saprbl : testing 70.112.63.202.sbl.spamhaus.org
20100813 13:01:12 saprbl : testing 70.112.63.202.bl.spamcop.net
20100813 13:01:12 saprbl : pass (time:401)
20100813 13:01:12 sapspf : v=spf1 include:spf-a.hotmail.com
include:spf-b.hotmail.com
include:spf-c.hotmail.com
include:spf-d.hotmail.com
include:_spf-ssg-a.microsoft.com ~all
20100813 13:01:12 sapspf : softfail (time:520)
20100813 13:01:12 sapcep : disabled
20100813 13:01:12 sapcbv : MX lookup: msn.com
20100813 13:01:12 sapcbv : total mx records: 5
20100813 13:01:12 sapcbv : mx: 65.55.37.120 mx4.hotmail.com
20100813 13:01:12 sapcbv : mx: 65.55.37.88 mx4.hotmail.com
20100813 13:01:12 sapcbv : mx: 65.55.92.184 mx4.hotmail.com
20100813 13:01:12 sapcbv : mx: 65.55.92.168 mx4.hotmail.com
20100813 13:01:12 sapcbv : mx: 65.54.188.72 mx4.hotmail.com
20100813 13:01:12 try mx : mx4.hotmail.com ip: 65.55.37.120
20100813 13:01:12 # connecting to 65.55.37.120
20100813 13:01:13 S: 220 col0-mc4-f39.Col0.hotmail.com Sending ......
20100813 13:01:13 C: NOOP WCSAP v2.11 Wildcat! Sender Authentication
Protocol
20100813 13:01:13 S: 250 OK
20100813 13:01:13 C: HELO [208.247.131.15]
20100813 13:01:13 S: 250 col0-mc4-f39.Col0.hotmail.com (3.11.0.113)
Hello [208.247.131.15]
20100813 13:01:13 C: MAIL FROM:<>
20100813 13:01:13 S: 250 <>....Sender OK
20100813 13:01:13 C: RCPT TO:<basdsndl137saowei(_at_)msn(_dot_)com>
20100813 13:01:13 S: 550 Requested action not taken: mailbox unavailable
20100813 13:01:13 C: QUIT
20100813 13:01:13 sapcbv : 550
20100813 13:01:13 finaltest : CBV GlobalResult=0 CodeResponse=550
20100813 13:01:13 result : reject (0)
20100813 13:01:13 smtp code : 550
20100813 13:01:13 reason : Rejected by WCSAP CBV
Relaxed SPF policy is a big waste of receiver resources.
Sure, the bounce would of catch this as a first try, but that would of
meant payload transfer and acceptance. Lets not forget the savings in
AV checking the DATA state or post smtp. Lets not forget about value
of not passing the email to the user which was OK for this transfer so
a user would of saw this.
IMV, it is better to reject at SMTP as best you do so so, rather than
passing on potentially harmful email to users.
--
Sincerely
Hector Santos
http://www.santronics.com