Douglas Otis wrote:
> The "exists" scheme does not seem to make any sense either,
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.
SPF macros offer %{l} for the local part and similar tricks.
As long as you stay within the limits listed in RFC 3696 you
can do whatever you like. The SPF spec. mentions potential
traps and pitfalls, 63, 255, 253, other magic numbers. Stick
to VCHAR plus space minus dot in derived domain labels, %{l}
does not yet come with a "ready for IMA / IEE" icon... :-)
> BATV signatures (with mutual arrangements), can be applied
> to allow a diversity of SMTP senders.
The arrangement could be that user B submits mail at MSA a with
MAIL FROM B@b. MSA a allows this and implements BATV resulting
in MAIL FROM batv-B@b. Later the MX of b would accept a bounce
to batv-B@b but not to B@b. Yes, that could work.
It's beyond me why user B doesn't simply use his MAIL FROM a@A
while sending via MSA a, but that wasn't the question... ;-)
The hardcore "bounces-to" fans would still hate it more than
SPF: With SPF they wouldn't need much cooperation from MON a
to publish their MON a route in addition to their preferred
MRN b return path. With BATV MON a would have to play along
and encode b@B -> batv-B@b precisely as expected by MRN b.
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.
> Receiving domains can also make exceptions for individuals
> that wish to "opt-out". Coverage does not need to be 100%
> to be an effective deterrent for DSN or auto-response
> exploits.
That concept has the nickname "forward-master-plan" in the SPF
community, it's the most simple solution to bypass SPF checks
on a per user base behind traditional 1123 5.3.6(a) forwarding.
> Alternatively, SPF would need a "per-user" lookup.
See above for %{l}. Not nice for DNS caches, but otherwise it
is possible. For premium accounts you can also offer per user
policies ("premium" support costs).
> 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. 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.
> BATV does not risk as many delivery issues, whereas SPF will
> when delivering to those using their Alma Mater email
> address, for example.
That's no argument, nobody needs to use his Alma Mater address
in the reverse path while in reality using an unrelated MSA xy.
If you're allowed to use MSA xy you will also have an address
related to xy, say user@xy, and that could forward all error
messages via Alma Mater to your real mailbox of the day. The
idea to analyze problems between xy and z by introducing a 3rd
party Alma Mater as "bounces to" is obscure: More potential
points of failure. Besides Alma Mater could offer its own MSA,
why use MSA xy if you want replies and bounces at Alma Mater ?
Now folks are free to be as stupid as they wish, and in theory
Alma Mater can support this by just not publishing FAIL. FAIL
is for those who desperately need it, not for folks celebrating
their first university address for the rest of their live.
> 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... ;-)
> 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).
Well, let's agree to disagree, I guess we finished another full
circle, and for the next round we'd need a fresh BATV draft.
Bye, Frank
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf