ietf-smtp
[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 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

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