On Mon, 2006-01-02 at 06:41 +0100, Frank Ellermann wrote: > Douglas Otis wrote: > > AFAIK it's a way to check if mail claiming to be from ses-x@y > was originally sent from x@y - if that's correct nothing is > wrong with the idea so far, domain y only needs a name server > returning 127.0.0.2 for ses-x.y and the "exists"-mechanism. This requires at least three and perhaps several more DNS lookups to resolve email-address authorization. Placing greater burdens on the recipient with additional external lookups does not make sense. > The "bounces-to" fans want to be free to use return-paths as > it pleases them, without discussing this with their MON of the > day, or with the MRN hit by the bounces. A transparent scheme could allow complete freedom by encoding a translated return-path in the BATV tag, which is de-encapsulated in a manner illustrated in VERP for a list-server. http://cr.yp.to/proto/verp.txt The opt-out list avoids this effort. Over time, nested tags could become a common method to deal with this issue. The exception lists seemed easier. > > SPF still allows any miscreant to exploit open-ended records > > Not really. You can't get a PASS claiming to send MAIL FROM me > without being a claranet.de customer, and fixing that last hole > is trivial, they could just implement 2476bis 6.1. Are you suggesting the MSA blocks submissions? How does that prevent a miscreant? > Of course a spammer will find tons of policies where he can get a > NEUTRAL result for forged mails. But by definition NEUTRAL is the > same as NONE (no policy), and IIRC we used MUSTard for this concept. Unfortunately this may also result in those with open-ended records becoming block-listed. : ( > > BATV does not risk as many delivery issues, whereas SPF will > > when delivering to those using their Alma Mater email > > address, for example. > There will be a > That's no argument, nobody needs to use his Alma Mater address > in the reverse path while in reality using an unrelated MSA xy. A transition period will last years, if not decades. Looking for a simple transition should consider this process. I agree, opt-out is not an optimal solution, and perhaps nesting would be preferable. > > With BATV, the number of DNS lookups is zero. > > Yes, and the number of rejected forged MAIL FROMs at the > primary victim based on BATV is also zero, you get what you > pay for, from the primary victim's POV nothing... ;-) When the recipient can better depend upon source identifiers for vetting email, then this improves abatement. In that regard, BATV does indeed provide the primary victim (the domain implementing BATV) much better protection. The expectation that SPF will directly prevent abuse is why authorization is being abused as authentication. Anyone can publish SPF records. Anyone can implement BATV. Preventing the success of the exploit will likely alter the behavior of the spammer as you suggested. Those implementing BATV will be much less likely targets, as this clearly indicates which sources are sending forged return-paths. Improving upon the source identifier block-list is where protection is obtained, and BATV helps in that compilation. > > Being able to ensure forged return-paths are not effective > > when returned would better realize the efficiencies of a > > store and forward system. > > Okay, SPF PASS offers only "it won't hit innocent bystanders", > not too shabby for my tastes. With SPF FAIL you also get "it > never reaches my existing users", together that's as powerful > as it can get before DATA (BDAT / BURL / whatever). The disagreement seems to be what abates abuse. No mechanism by itself abates abuse. I like the phrase "jumping through hoops" used by John Levine. Erecting more hoops will not abate abuse. An authorization scheme will not conform to existing practices, nor does it provide a suitable identifier upon which reputation can be applied. Unfortunately, as reputation is the active ingredient in abatement, the unfair misuse of authorization as a source identifier is certainly inevitable. This is especially true when open-ended lists are needed and abuse persists. -Doug _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf