[Top] [All Lists]

Re: NDNs considered harmful

2010-08-13 13:22:19

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
20100813 13:01:12 saprbl     : testing
20100813 13:01:12 saprbl     : pass (time:401)
20100813 13:01:12 sapspf     : v=spf1
20100813 13:01:12 sapspf     : softfail (time:520)
20100813 13:01:12 sapcep     : disabled
20100813 13:01:12 sapcbv     : MX lookup:
20100813 13:01:12 sapcbv     : total mx records: 5
20100813 13:01:12 sapcbv     : mx:
20100813 13:01:12 sapcbv     : mx:
20100813 13:01:12 sapcbv     : mx:
20100813 13:01:12 sapcbv     : mx:
20100813 13:01:12 sapcbv     : mx:
20100813 13:01:12 try mx     : ip:
20100813 13:01:12 # connecting to
20100813 13:01:13 S: 220 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 []
20100813 13:01:13 S: 250 ( Hello []
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.


Hector Santos

<Prev in Thread] Current Thread [Next in Thread>