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(_at_)y
was originally sent from x(_at_)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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf