Hi Stephen, thanks for the review comments. -05 has fixed the typoes and it
provides an example using the anonymous well-known names as requested.
Here is the relevant text in -05.
It is possible to have name collision with well-known names because
Kerberos as defined in [RFC4120] does not
The proposed text looks good.
--larry
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam Hartman
Sent: Thursday, March 20, 2008 7:57 AM
To: ietf@ietf.org
Cc: [EMAIL PROTECTED]
Subject: [Ietf-krb-wg] Late Last Call Comment: draft-ietf-krb-wg-naming-04.txt
Sam and I got together today and discussed this issue. we believe by adding the
following text then we have the right trade-off.
If anonymous PKINIT is used, the returned realm name MUST be the anonymous
realm.
All the issues in this thread are assumed to have been addressed with this
propos
The last sentence in the previous email was not completed before the send
button was hit inadvertently. It should read "This is pending krb-wg working
group validation.".
--larry
-Original Message-
From: Larry Zhu
Sent: Sunday, July 27, 2008 8:00 AM
To: 'Sam Hartman'
Cc: [EMAIL PROTECTE
> 'Sieve Email Filtering: Reject and Extended Reject Extensions '
> as a Proposed Standard
IMO this draft is _not_ ready for publication on standards track.
The "Joe Job" in the abstract is a deviation from current usage:
Forging "plausible" return-paths (to survive call back and SPF
FAIL chec
> > 'Sieve Email Filtering: Reject and Extended Reject Extensions '
> > as a Proposed Standard
> IMO this draft is _not_ ready for publication on standards track.
I disagree.
> The "Joe Job" in the abstract is a deviation from current usage:
> Forging "plausible" return-paths (to survive call
<[EMAIL PROTECTED]> wrote:
[Joe Job]
> This is the original meaning of the term - you can find the
> history behind the term in the Wikipedia entry.
Yes, I recall it, about six years ago, when spammers figured
out that they can actually abuse any plausible return-path.
> You are correct to sa
The IESG wrote:
> 'Sieve Email Filtering: Reject and Extended Reject Extensions '
> as a Proposed Standard
The draft wants to "update" RFC 3028, but this RFC was obsoleted
by RFC 5228. Good riddance wrt 'reject', reviving this "CANSPAM"
recipe appears to be a bad idea.
LMTP happens after fina
