william(at)elan.net wrote:
I sent the following email to chairs:
| I think it would be right to summarize today's [Monday's]
| discussion on jabber session that there was a consensus that
| the use of Resent-headers as written in last published
| version of marid-core does not correspond to their intended
| use as specified in RFC2822
While that's true in a certain sense I'd still think that the
PRA usage didn't _conflict_ with the intended use in RfC 822.
Or in other words, I've never seen any Resent-* headers in the
wild (or it's more than 10 years ago, and I forgot it... ;-)
The potential _abuse_ of Resent-* as dummy PRA is of course one
of several real problems with PRA.
I suspect that from the start there were some agreements that
MARID will work on bringing CallerID up for standartization
ACK. And I always wanted a RfC for classic SPF as the working
incarnation of RMX.
at the same time we had AOL that also withdraw its support
AFAIK they (AOL) always supported classic SPF. This whole
unified sender-caller-domainkey-Id episode was a nightmare.
I'll wait for answer from Mark on this.
I'd be not surprised if some of us have had it with the IETF
and internet drafts for this year. Or at least this week.
Like Meng said, we're now free to proceed with SPF work and
extending SPF to other identities (like HELO, which in MARID
was covered by CSV).
The original MARID plan was to discuss CSV after "Sender-Id"
(now again SPF), and I have only vague ideas about CSV. It's
much less expensive than SPF, if I got this right, and it does
not conflict with spf2.0/mfrom.
http://elvey.com/it/sieve/draft-ietf-marid-spf3-00.txt
That appears to be essentially the same as protocol-03, with
helo replacing pra (not everywhere). Therefore I guess that
there's an additional text like mailfrom-00, a draft-helo-00
maybe (?)
What's the basic idea ? In mailfrom-00 we already have a
mandatory postmaster(_at_)helo test for bounces (empty MAIL FROM).
In classic SPF there was also an _optional_ HELO test in the
case of normal MAIL FROMs (not empty). So is this "spf3"
simply a spf2.0/helo scope, allowing for different helo and
mfrom sender policies ? Just a missing piece of v=spf1, like
the header with SPF-results ?
What do you have in mind (in addition to "mfrom") ?
HELO, PTR
Something wrong with MTAMARK ? SPF is _very_ expensive, with
its macro language / include: / redirect=
My concept of MTAMARK is, that it helps to maintain DUL-lists.
SPF would be overkill for this job.
Publishing experimental RFC would be enough to get new RR
type.
Okay, I've no problem with this plan, as long as classic SPF
can continue to (ab)use TXT records for some time (a decade ?)
The arguments in MARID by Jim Lyon & Co., why we need TXT at
the moment, were convincing. And if in doubt I can always ask
my nslookup.exe (IBM compiled some BSD code, SCCS says 1991 ;-)
what it thinks about new DNS tricks, and nslookup votes "no".
You'll no doubt notice that draft was published as individual
submission.
Yes, I know, but AFAIK the author isn't on this list, and his
draft isn't ready to be published as RfC.
PRA is dead. I have some reason to believe it might not be
accepted even for EXPERIMENTAL RFC on technical grounds.
I doubt that will matter to Microsoft, though.
LOL. Bye, Frank