On Jun 17, 2008, at 3:41 AM, Charles Lindsey wrote:
> On Mon, 16 Jun 2008 15:51:07 +0100, Douglas Otis <[EMAIL PROTECTED]
> abuse.org>
> wrote:
>
>> Protection depends upon which ADSP assertion is made. A LOCKED
>> assertion will cause a message to be dismissed when ADSP compliance
>> is en
On Mon, 16 Jun 2008 15:51:07 +0100, Douglas Otis <[EMAIL PROTECTED]>
wrote:
> Protection depends upon which ADSP assertion is made. A LOCKED
> assertion will cause a message to be dismissed when ADSP compliance is
> enforced. Acceptance of messages with invalid signatures from mailing
> lists
On Jun 16, 2008, at 2:23 AM, Charles Lindsey wrote:
> On Fri, 13 Jun 2008 18:32:07 +0100, Douglas Otis <[EMAIL PROTECTED]
> abuse.org>
> wrote:
>
>> A Practice should be defined by its specification to cover specific
>> transport protocols when being asserted by transmitting domains.
>> It
On Fri, 13 Jun 2008 18:32:07 +0100, Douglas Otis <[EMAIL PROTECTED]>
wrote:
> A Practice should be defined by its specification to cover specific
> transport protocols when being asserted by transmitting domains. It
> is unreasonable to suggest all transport protocols that might ever use
> DKIM
On Jun 13, 2008, at 1:17 AM, Charles Lindsey wrote:
> On Wed, 11 Jun 2008 18:06:57 +0100, Douglas Otis <[EMAIL PROTECTED]
> abuse.org>
> wrote:
>
>
>> Which TLDs should be ignored? Imposing SMTP domain requirements will
>> likely reveal a need to make many exceptions. Do you agree there
>> sho
On Jun 13, 2008, at 1:17 AM, Charles Lindsey wrote:
> On Wed, 11 Jun 2008 22:52:12 +0100, Douglas Otis <[EMAIL PROTECTED]
> abuse.org>
> wrote:
>
>> Disagree. Unlike DKIM (RFC4871) where use is self evident, a
>> practice assertion must declare which transport protocol is
>> covered. Other
On Wed, 11 Jun 2008 18:06:57 +0100, Douglas Otis <[EMAIL PROTECTED]>
wrote:
> Which TLDs should be ignored? Imposing SMTP domain requirements will
> likely reveal a need to make many exceptions. Do you agree there
> should be a means for making exceptions? Whether making address
> assignments
On Wed, 11 Jun 2008 22:52:12 +0100, Douglas Otis <[EMAIL PROTECTED]>
wrote:
> Disagree. Unlike DKIM (RFC4871) where use is self evident, a practice
> assertion must declare which transport protocol is covered. Otherwise
> it is impossible to discern specifically what is being asserted. Are
> m
On Jun 11, 2008, at 12:00 PM, Frank Ellermann wrote:
> Douglas Otis wrote:
>
>> Which TLDs should be ignored?
>
> It's up to the implementors of the proprietary mail exchange you
> have in mind to get this right, if they wish to implement the
> Internet message format they will find some fres
Douglas Otis wrote:
> Which TLDs should be ignored?
It's up to the implementors of the proprietary proprietary mail
exchange you have in mind to get this right, if they wish to
implement the Internet message format they will find some fresh
specifications in 2822upd and RFC.ietf-usefor-usefor.
On Jun 11, 2008, at 1:48 AM, Charles Lindsey wrote:
> On Tue, 10 Jun 2008 18:34:57 +0100, Douglas Otis <[EMAIL PROTECTED]
> abuse.org>
> wrote:
>
>> On Jun 9, 2008, at 9:21 PM, Jim Fenton wrote:
>
>>> Since it apparently isn't clear: I am proposing retaining the
>>> NXDOMAIN domain validity c
On Tue, 10 Jun 2008 18:34:57 +0100, Douglas Otis <[EMAIL PROTECTED]>
wrote:
> On Jun 9, 2008, at 9:21 PM, Jim Fenton wrote:
>> Since it apparently isn't clear: I am proposing retaining the
>> NXDOMAIN domain validity check as a MUST. It is only the MX and A/
>> check that I'm proposing b
On Jun 9, 2008, at 9:21 PM, Jim Fenton wrote:
> Douglas Otis wrote:
>>
>> On Jun 9, 2008, at 3:38 PM, Jim Fenton wrote:
>>> Dave Crocker wrote:
So we need to be careful about assuming that any of these tests
are likely to be "free". In fact, one bit of feedback I got was
On Jun 9, 2008, at 8:55 PM, Scott Kitterman wrote:
> On Monday 09 June 2008 20:11, Frank Ellermann wrote:
>> John Levine wrote:
change the SHOULD [check MX & A/] to a MAY. With
that change, I'm happy with the text John proposes.
>>>
>>> OK by me.
>>
>> Hm, it is a border case, why n
Scott Kitterman wrote:
> punt on that and just say the ADSP only applies to domains
> that exist. I think we perhaps we can leave how to determine
> this as an implementation detail. The last 1% of
> agreement/interoperability isn't worth it.
It's an idea, but somebody here confused NODATA an
Douglas Otis wrote:
>
> On Jun 9, 2008, at 3:38 PM, Jim Fenton wrote:
>> Dave Crocker wrote:
>>>
>>> So we need to be careful about assuming that any of these tests are
>>> likely to be "free". In fact, one bit of feedback I got was
>>> explicit about these additional tests as costing too much.
John Levine wrote:
>> change the SHOULD [check MX & A/] to a MAY. With
>> that change, I'm happy with the text John proposes.
> OK by me.
Hm, it is a border case, why not just say "MUST either
check [2821bis] or as minimal approximation [nxdomain]".
If you really like MAY better I think "MA
On Jun 9, 2008, at 3:38 PM, Jim Fenton wrote:
> Dave Crocker wrote:
>>
>> So we need to be careful about assuming that any of these tests are
>> likely to be "free". In fact, one bit of feedback I got was
>> explicit about these additional tests as costing too much. They
>> had tried and f
In view of the fact that there is incremental cost, I would like to
suggest that we change the SHOULD [check MX & A/] to a MAY. With
that change, I'm happy with the text John proposes.
OK by me.
R's,
John___
NOTE WELL: This list operates accordin
John Levine wrote:
* levine-adsp-00 provides a superset of methods for *how* to
determine if the domain exists: the NXDOMAIN test and the "check MX &
A/" method from SMTP. It leaves it up to the implementation to
choose the algorithm that work
At 09:14 04-06-2008, Dave Crocker wrote:
>In the interest of accuracy:
>
>I have been probing some email receive-side folk, about their
> call-back or
>verification steps like this that they conduct. Generally, the
>range of tests
>is of these types.
>
> Unfortunately, it is rarely based
>> What I should have said was that recipients MUST do the NXDOMAIN check
>> and SHOULD do the more comprehensive 2821 check. It's SHOULD since it
>> is my impression that many MTAs do it anyway, so there's no incremental
>> cost.
>>
>> This gives senders a baseline that they know receivers will d
On 04/06/2008 08:02, "John Levine" <[EMAIL PROTECTED]> wrote:
> What I should have said was that recipients MUST do the NXDOMAIN check
> and SHOULD do the more comprehensive 2821 check. It's SHOULD since it
> is my impression that many MTAs do it anyway, so there's no incremental
> cost.
>
> Thi
John Levine wrote:
* levine-adsp-00 provides a superset of methods for *how* to
determine if the domain exists: the NXDOMAIN test and the "check MX &
A/" method from SMTP. It leaves it up to the implementation to
choose the algorithm that works best for it.
>
John Levine wrote:
* levine-adsp-00 provides a superset of methods for *how* to
determine if the domain exists: the NXDOMAIN test and the "check MX&
A/" method from SMTP. It leaves it up to the implementation to
choose the algorithm that works best for it.
>>> * levine-adsp-00 provides a superset of methods for *how* to
>>> determine if the domain exists: the NXDOMAIN test and the "check MX &
>>> A/" method from SMTP. It leaves it up to the implementation to
>>> choose the algorithm that works best for it.
What I should have said wa
Good summary, Tony. Here's my perspective:
Tony Hansen wrote:
> Tony Hansen wrote:
>
>> *levine-adsp-00 provides a superset of methods for *how* to
>> determine if the domain exists: the NXDOMAIN test and the "check MX &
>> A/" method from SMTP. It leaves it up to the impleme
And then I forgot to change the subject line. Sigh. - Tony
Tony Hansen wrote:
> Stephen Farrell wrote:
> > Please just answer "keep", "modify", or "remove" in this thread, and
> > use a different subject line for any discussion.
>
> (Using a different subject line as requested.)
>
> My conclus
28 matches
Mail list logo
