Julian Mehnle wrote:
no, I didn't want to get rid of that part
Okay, then I think that's clear: Wayne + Mark + you agreed.
so far nobody disagreed, and for the Sender-ID folks it's
also better, even if Andy+Men^Wthey don't see it this way.
I'll include it in my collective -01pre5 patch in a day
or two.
Discuss this with Wayne, otherwise you could end up with a
new -01pre6, your -01pre5 patch, pending Council decisions
(Mark's article in spf-council plus two formal CfVs here),
and that could be messy for the editor.
In essence SPF recreates the old source-route idea.
Huh? You could say that about SRS, but _SPF_?
Try 'levine ellermann "quixotic quest"' in your favourite
search engine and enjoy.
SMTP as designed by Jon Postel in STD 10 still had a literal
"reverse path", not some arbitrary "bounces-to" as claimed
by Dave Crocker in his mail-arch.
With a literal "reverse path" forwarders would be forced to
eat all bounced crap they've forwarded before they pass it
on to the forged address. That would be a PITA, therefore
they'd never forward crap with a dubious "reverse path" in
the first place => 551. Sounds familiar ?
[SHOULD - MAY - SHOULD]
IIRC this deliberately fuzzy (AKA diplomatic) wording is the
result of some earlier discussions about exactly this issue.
Wayne already said that he would use the "SHOULD is not MUST"
exit from this timeout dilemma. I'd also use it in a simple
implementation (two threads, with one thread it's as you said
no issue, because then you'd never have two pending queries)
"Forget it if you don't like it" is not my idea of a SHOULD,
otherwise I'd press very hard for a SHALL NOT instead of the
NOT RECOMMENDED in the subject. IMHO a SHOULD is no nonsense.
If it means something I don't see - like "you really ought to
have a SPF cache layer" - then let's say so in the SPF spec.
Bye, Frank