wayne wrote:
Unless I'm missing something, this appears to be a variation
of the "whitelist forwarders on the receiving end" (section
9.3.3.1 of the spf-classic I-D).
Yes, that's also my understanding - unlike you I didn't find
the page explaining the hardcore technical facts, but after
some wrong guesses I hope I now got the idea, as far as it's
related to SPF.
I like the way April figured out how to save most of the
state in the local part of the email address, but in
reality, I'm not sure that is such a huge savings.
For Hannah that was a very important isssue, because they
hate any extra-databases - okay, that was about SRS / SES.
"VARA" is apparently - among other things - some kind of
a "reverse SRS". In that sense it might be a better idea
than Radu's "forwardmaster" or the "forwardmaster plan".
I'm not sure that is, in practice, that much simplier
than simply knowing that <real-localpart> wishes to
whitelist <forwarder.tld>.
"Knowing" is a database with "per user white lists", that
would be the "forwardmaster" idea - or at least that's what
I think Radu meant - we never completely agreed what it is,
because I always thought it should be about HELO FQDNs. ;-)
In the VARA case I also started an immediate search for a
HELO, but April stopped me before it got out of hand, it's
just IP -> q=ptr -> name(s) -> q=a -> IP(s) -> match ?
I can't tell if that's always a good plan, you once talked
about hundreds of names. OTOH if we can say that everybody
can arrange a "v=spf1 a -all" for HELO, then VARA can also
say that mail forwarders should get this PTR issue right
for the IPs of their mailouts.
[mxout]
If the rDNS identity proposals (MTAMark, etc.) were ever
really considered, I would have probably favored .mxout.
over those. (It has been over a year, I would need to
review everything to be sure.)
Yes, I also completely forgot this part, the introduction
of Caller-ID hurt not only SPF but other good ideas, too :-(
Bye, Frank