The IESG has received an appeal regarding the previously approved
draft-kucherawy-sender-auth-header-20. The appeal text can be
found here:
http://www.ietf.org/IESG/APPEALS/appeal-otis-2009-02-16.txt
The IESG plans to make a decision in the next few weeks, and solicits
comments on the concern
The IESG wrote:
The IESG has received an appeal regarding the previously approved
draft-kucherawy-sender-auth-header-20. The appeal text can be
found here:
http://www.ietf.org/IESG/APPEALS/appeal-otis-2009-02-16.txt
Greetings.
This note offers comments on the appeal, draft-otis-auth-he
On Thu, 19 Feb 2009 18:04:31 -0800 Dave CROCKER wrote:
>This appeal lacks merit on basic points.
>
+1. I don't think I could have said it better myself.
I was involved in the MARID and DKIM working groups and was involved in the
group that helped put together this draft. All these points hav
system
such as SAML you actually have three classes of data with the introduction of
attributes.
From: ietf-boun...@ietf.org on behalf of Scott Kitterman
Sent: Thu 2/19/2009 9:32 PM
To: ietf@ietf.org
Subject: Re: Comments requested on recent appeal to the IESG
> http://www.ietf.org/IESG/APPEALS/appeal-otis-2009-02-16.txt
This appeal boils down to "someone might misuse it so don't
standardize it." Is there any standard to which someone couldn't have
made a similar objection?
Much of the bad stuff they say about SPF and Sender-ID is correct, but
it'll
At 9:00 PM -0800 2/19/09, Hallam-Baker, Phillip wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
boundary="_=_NextPart_001_01C99318.3582B8D8"
Just as a matter of observation, there is not and never has been a
security requirement to rigidly sepa
Stephen Kent wrote:
At 9:00 PM -0800 2/19/09, Hallam-Baker, Phillip wrote:
Just as a matter of observation, ...
...
I have not read the doc in
question,...
Hey guys. As someone who is frequently faced with trying to parse out what are
and are not the commonly held views among the
At 10:57 20-02-2009, Murray S. Kucherawy wrote:
All of the issues Mr. Otis raises have been given substantially more than a
normal amount of consideration, yet they have failed to attract any detectable
consensus. Disagreement with both his concerns and his proposed remedies is
ample and well-do
At 7:06 PM -0800 2/20/09, Dave CROCKER wrote:
Stephen Kent wrote:
At 9:00 PM -0800 2/19/09, Hallam-Baker, Phillip wrote:
Just as a matter of observation, ...
...
I have not read the doc in
question,...
Hey guys. As someone who is frequently faced with trying to parse
out what are
On Feb 19, 2009, at 6:04 PM, Dave CROCKER wrote:
The IESG wrote:
The IESG has received an appeal regarding the previously approved
draft-kucherawy-sender-auth-header-20. The appeal text can be
found here:
http://www.ietf.org/IESG/APPEALS/appeal-otis-2009-02-16.txt
This note offers com
On Feb 20, 2009, at 1:44 AM, John Levine wrote:
http://www.ietf.org/IESG/APPEALS/appeal-otis-2009-02-16.txt
This appeal boils down to "someone might misuse it so don't
standardize it." Is there any standard to which someone couldn't
have made a similar objection?
The appeal is in rega
On Sun, 22 Feb 2009 13:11:26 -0800, Doug Otis wrote:
> > This appeal boils down to "someone might misuse it so don't
> > standardize it." Is there any standard to which someone couldn't
> > have made a similar objection?
>
> The appeal is in regard to offering recipients potentially misleadin
On Feb 23, 2009, at 12:32 AM, Murray S. Kucherawy wrote:
On Sun, 22 Feb 2009 13:11:26 -0800, Doug Otis wrote:
This appeal boils down to "someone might misuse it so don't
standardize it." Is there any standard to which someone couldn't
have made a similar objection?
The appeal is in rega
Doug Otis wrote:
Since *authorization* does not *authenticate* a domain as having
originated a message, this leaves just the IP address of the SMTP client
as a weakly "authenticated origin identifier". The IP address of the
SMTP client is the input for Sender-ID or SPF *authorization*
mechani
Doug Otis wrote:
Since *authorization* does not *authenticate* a domain as having
originated a message, this leaves just the IP address of the SMTP
client as a weakly "authenticated origin identifier". The IP
address of the SMTP client is the input for Sender-ID or SPF
*authorization* mec
Douglas Otis wrote:
Received: by SMTP id j2cs23447wfe;
Tue, 24 Feb 2009 09:51:01 -0800 (PST)
Return-Path:
Authentication-Results: trusted-isp.com; spf=pass smtp.mail=example.com
...
--- or ---
Received: by SMTP id j2cs23447wfe;
Tue, 24 Feb 2009 09:51:01 -0800 (PST)
Return-Path: (SMT
@ietf.org
Subject: RE: Comments requested on recent appeal to the IESG
At 9:00 PM -0800 2/19/09, Hallam-Baker, Phillip wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
boundary="_=_NextPart_001_01C99318.3582B8D8"
On Feb 26, 2009, at 10:47 AM, Alessandro Vesely wrote:
Douglas Otis wrote:
3) Separate SMTP clients share the same IP addresses.
(Unfortunately this is also a common practice. Brazil, Poland, and
other places have many ISPs that expect hundreds or thousands of
customers to run outboun
Hi,
Douglas Otis wrote:
There are hundreds of thousands of legitimate SMTP clients in comparison
to hundreds of millions of domains.
My understanding is that recipients are only interested in a few
domain names: their company, their banks, their customers, their
providers, and the like. Whil
On Feb 27, 2009, at 1:12 AM, Alessandro Vesely wrote:
Douglas Otis wrote:
There are hundreds of thousands of legitimate SMTP clients in
comparison to hundreds of millions of domains.
My understanding is that recipients are only interested in a few
domain names: their company, their banks,
Douglas Otis wrote:
ESPs optimize profits by reducing their
support calls. To do this, they might reduce erroneous rejections by
tweaking SPF to make guesses. As such, it is not safe to assume that
because the ESP accepted a message from an authorized SMTP client, that:
A) the SMTP client
On Feb 28, 2009, at 4:14 AM, Alessandro Vesely wrote:
Douglas Otis wrote:
The safety of an assumption about an authorizing domain originating
a message depends upon the reputation of the SMTP client for its
protection of the PRA and Mail From. Unfortunately, identifiers
for the SMTP cl
22 matches
Mail list logo
