Subject: Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463
From: Dave Crocker <[email-masked]>
To: [email-masked]
Cc: Jeff Macdonald <[email-masked]>
Date: Sat, 25 Aug 2007 13:27:51 -0400
List-Id: <ietf-smtp.imc.org>

[email-masked] wrote:
> My issue is with moving some 7.n codes to 8.m codes. I see no problem with
> defining 8 as the place for all future policy codes and putting a bunch of them
> in there. 

Right.

It is probably worth mentioning that Jeff is not pursuing this matter of a 
personal whim.

There is a formal effort in MAAWG (anti-abuse) to formulate extended SMTP 
codes that cover policy-related rejections.

Picking up a point made earlier in this thread:  while the decision is a 
matter of local policy, it turns out that most of the range of local policy 
decisions comes from pretty stable repertoire, with respect to abuse-related 
rejections.

So the MAAWG community is simply looking for a vehicle that will provide 
standardized protocol embodiment of the kinds of information that common 
anti-abuse discussions already demonstrate, when communicating why a message 
or an author or an operator has been rejected.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Sat, 25 Aug 2007 13:20:02 -0400
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463
Sender: [email-masked]

(chiming in a bit late.)

I think the issue is providing additional text, which is friendly to reader 
comprehension, versus replacing existing text, which contains standardized data.

Two forms.  Different intended consumers.  Each useful.

d/

Tony Finch wrote:
> On Wed, 8 Aug 2007, Ned Freed wrote:
>> THe obvious rationale is a human factors one: The user doesn't speak the
>> language the original error text is in.
> 
> Right, but in many cases if the user wants help with the error then
> they'll have to forward the DSN to a postmaster who does understand it,
> and the postmaster will be much happier if they don't have to grep through
> gigabytes of logs to find out the real error message because some crapware
> deleted or truncated it.
> 
> Tony.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Wed, 15 Aug 2007 00:12:18 -0400
From: Tony Hansen <[email-masked]>
To: ietf-822 mailing list <[email-masked]>
CC: SMTP Interest Group <[email-masked]>, LEMONADE WG <[email-masked]>, IMAP extensions mailing list <[email-masked]>, EAI WG <[email-masked]>, POP3 extensions mailing list <[email-masked]>, USEFOR WG <[email-masked]>, SIMPLE WG <[email-masked]>
Subject: Re: Mailing List Last Call for 2822 update internet-draft
Sender: [email-masked]

The mailing list last call for the 2822 update is now over.

I believe we have mailing list consensus on the issues that have been
raised during the last call. After an updated draft is posted by Pete,
we'll be moving the draft forward to IETF last call.

	Tony

Tony Hansen wrote:
> There have been some comments on draft-resnick-2822upd-* but they have
> dwindled down to none.
> 
> This is a "formal" Mailing List Last Call on
> draft-resnick-2822upd-02.txt. The last call will last for two weeks
> time, ending on August 10, 2007.
> 
> The document will be discussed on the 822 mailing list,
> <[email-masked]>. Please send your comments there.

From: "Sabahattin Gucukoglu" <[email-masked]>
To: [email-masked]
Date: Thu, 09 Aug 2007 15:25:25 +0100
Subject: Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463
CC: [email-masked]
Content-description: Mail message body
Sender: [email-masked]

Hi Ned,

Translating ESCs to readable plaintext is an exciting proposition but only 
if a message or other user interface containing the translation does not 
lose the original plaintext portion in the original DSN report without the 
user's consent.  That's simply a courtesy and, while I'd like to think 
ESCs can convey every possibility with good enough gradation to be useful, 
obviously there's the possibility that the code won't be a substitute for 
the human-readable supplemental lines provided by the sending MTA.  
Whether that's important to a non-English user is obviously hard to say, 
but it wouldn't be a problem in any event if every MUA actually did 
translation of the machine-readable portion for itself.  Since (as far as 
I can see) they do not and the technique is mostly reserved by automatic 
robots (MLMs, etc), the only question now remaining is how we might let 
MTAs rewrite DSNs on behalf of our non-English-speaking friends who use 
MUAs that will not translate.

For me, I'm thinking the answer is that the MTA delivering my mail send 
not only the DSN to my mailbox but also a rewritten version of DSNs it 
transports for delivery to local users as detected by a null sender and 
multipart/report parts; the text part of the report can tell me about the 
original copy I've been sent (multipart/report MIME parameters telling of 
the original Message-Id, perhaps, and how this is only a translation?) and 
contains an enumeration and translation of status in the original's 
machine-readable section.  The machine-readable section could, 
furthermore, also be rewritten such that parenthetic text be translated to 
a local language.  The resulting message should be a valid DSN in and of 
itself and, if local users chose, could be the only version of a DSN 
received (the original being discarded - although perhaps there are 
dangers there).  Also, this service is more-or-less exclusively useful to 
users reading mail with user agents, since the criticality of multiple 
DSNs for a single transaction being misinterpreted by a computer program 
to mean multiple identical failures (EG: MLMs seeing two failed sends when 
only one is intended) might be significant.  There would have to be some 
breathing room somewhere in the spec to avoid that possibility if this 
sort of thing were to be preferable.  Alternatively, if it isn't actually 
necessary to preserve the machine-readability of translations, then 
breaking the DSN format isn't an issue and the problem goes away.  The 
point is to have machine-assisted translation but only if the kind of 
rewriting done isn't destructive, and I think a separate message is the 
best way, although MIME encapsulation is just as likely to work.

As a sidenote: sendmail seems to do a limited amount of translation on 
SMTP responses containing ESCs.  You can find them in DSN transcripts in 
the plaintext portion of the report.  The translations are not thorough 
and are based as much on the code as on the state sendmail's client code 
was in when it hit trouble.

Cheers,
Sabahattin

-- 
Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
Address harvesters, snag this: [email-masked]
Phone: +44 20 88008915
Mobile: +44 7986 053399
http://sabahattin-gucukoglu.com/

Date: Thu, 9 Aug 2007 15:12:32 +0100
From: Tony Finch <[email-masked]>
To: Ned Freed <[email-masked]>
cc: [email-masked], Peter J Holzer <[email-masked]>, [email-masked]
Subject: Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463
Sender: [email-masked]

On Wed, 8 Aug 2007, Ned Freed wrote:
>
> THe obvious rationale is a human factors one: The user doesn't speak the
> language the original error text is in.

Right, but in many cases if the user wants help with the error then
they'll have to forward the DSN to a postmaster who does understand it,
and the postmaster will be much happier if they don't have to grep through
gigabytes of logs to find out the real error message because some crapware
deleted or truncated it.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR
MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

From: [email-masked]
Cc: [email-masked], Peter J Holzer <[email-masked]>, [email-masked]
Date: Wed, 08 Aug 2007 17:39:16 -0700 (PDT)
Subject: Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463
To: Tony Finch <[email-masked]>
Sender: [email-masked]

> On Wed, 8 Aug 2007, [email-masked] wrote:
> >
> > > I think Lotus Notes/Domino does this. At least it replaces the first
> > > part of a multipart/report message with a text of its own, and this text
> > > seems to be vaguely related to the enhanced status code.
> >
> > Interesting. One of the purposes behind having a machine-readable part was to
> > facilitate this sort of thing. It is nice to hear that someone is actually
> > doing it.

> It isn't nice if the implementation is as broken as the above suggests
> (and in my experience Lotus Notes is the worst for mangling messages).

Well, it wouldn't be good if there's no way to get at the original text, or
if the use of the second part to regnerate the first is done incompetently.

> Any
> guess at a reason based on the status code should be in addition to, not
> instead of, the server's human-readable error text.

THe obvious rationale is a human factors one: The user doesn't speak the
language the original error text is in. 

> Removing the first
> part of a multipart/report message is utterly braindead since it is the
> only part of a DSN that can be properly internationalized and therefore
> has a chance of being understandable.

Removing the part entirely may be braindead but please explain how, when you
are in receipt of a DSN containing the typical first part written in bad
"Internet English" it can be reasonably translated into, say, Chinese.

				Ned

Date: Wed, 8 Aug 2007 17:44:09 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: Peter J Holzer <[email-masked]>, [email-masked]
Subject: Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463
Sender: [email-masked]

On Wed, 8 Aug 2007, [email-masked] wrote:
>
> > I think Lotus Notes/Domino does this. At least it replaces the first
> > part of a multipart/report message with a text of its own, and this text
> > seems to be vaguely related to the enhanced status code.
>
> Interesting. One of the purposes behind having a machine-readable part was to
> facilitate this sort of thing. It is nice to hear that someone is actually
> doing it.

It isn't nice if the implementation is as broken as the above suggests
(and in my experience Lotus Notes is the worst for mangling messages). Any
guess at a reason based on the status code should be in addition to, not
instead of, the server's human-readable error text. Removing the first
part of a multipart/report message is utterly braindead since it is the
only part of a DSN that can be properly internationalized and therefore
has a chance of being understandable.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR
MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

From: [email-masked]
Cc: [email-masked]
Date: Wed, 08 Aug 2007 07:16:57 -0700 (PDT)
Subject: Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463
To: Peter J Holzer <[email-masked]>
Sender: [email-masked]

> On 2007-08-06 10:08:51 -0700, [email-masked] wrote:
> > But examination and use of enhanced status codes is hardly limited to MTAs -
> > indeed, while MTAs have reason to find and copy these codes around they
> > generally don't need to look at their values. The same canont be said for
> > various other agents such as MUAs wanting to localize DSNs or list managers
> > wanting to automatically process DSNs. I cannot cite an example of a deployed
> > MUA that does DSN translation but that doesn't mean there aren't any.

> I think Lotus Notes/Domino does this. At least it replaces the first
> part of a multipart/report message with a text of its own, and this text
> seems to be vaguely related to the enhanced status code.

Interesting. One of the purposes behind having a machine-readable part was to
facilitate this sort of thing. It is nice to hear that someone is actually
doing it.

> I wonder if Outlook/Exchange does something similar. The fact that
> Exchange (by default?) sends DSNs with only an enhanced status code and no
> human readable explanation at all is a strong hint that the programmers
> expected the recipient's agent to fill in the human readable explanation.

Can anyone else confirm whether or not Outlook does this when talking to
Exchange?

				Ned

Date: Tue, 7 Aug 2007 23:08:36 +0200
From: "Peter J. Holzer" <[email-masked]>
To: [email-masked]
Subject: Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463
Mail-Followup-To: [email-masked]
Sender: [email-masked]

--l76fUT7nc3MelDdI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2007-08-06 10:08:51 -0700, [email-masked] wrote:
> But examination and use of enhanced status codes is hardly limited to MTA=
s -
> indeed, while MTAs have reason to find and copy these codes around they
> generally don't need to look at their values. The same canont be said for
> various other agents such as MUAs wanting to localize DSNs or list manage=
rs
> wanting to automatically process DSNs. I cannot cite an example of a depl=
oyed
> MUA that does DSN translation but that doesn't mean there aren't any.

I think Lotus Notes/Domino does this. At least it replaces the first
part of a multipart/report message with a text of its own, and this text
seems to be vaguely related to the enhanced status code.

I wonder if Outlook/Exchange does something similar. The fact that
Exchange (by default?) sends DSNs with only an enhanced status code and no
human readable explanation at all is a strong hint that the programmers
expected the recipient's agent to fill in the human readable explanation.

	hp

--=20
   _  | Peter J. Holzer    | I know I'd be respectful of a pirate=20
|_|_) | Sysadmin WSR       | with an emu on his shoulder.
| |   | [email-masked]         |
__/   | http://www.hjp.at/ |	-- Sam in "Freefall"

--l76fUT7nc3MelDdI
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--l76fUT7nc3MelDdI--

Date: Mon, 06 Aug 2007 20:34:05 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463
Sender: [email-masked]

[email-masked] wrote:

>>On Sat, Aug 04, 2007 at 07:25:14PM -0400, John C Klensin wrote:
>>    
>>
>>>--On Saturday, 04 August, 2007 19:09 -0400 Jeff Macdonald
>>><[email-masked]> wrote:
>>>      
>>>
>>>and existing client implementations to adapt to the new sub series.
>>>      
>>>
>>I'm not aware of any MTAs that pay attention to extended SMTP codes.
>>Could you supply some examples?
>>    
>>
>The MTA I work on (PMDF/SJSMS) has had code to process enhanced status codes in
>place for almost a decade. This includes looking at the second and third value
>of the status code, althogh to be fair this is only done when gatewaying to
>non-SMTP environments. In the SMTP-only world the code is extracted from
>responses and copied into DSNs and whatnot, but I don't believe the second and
>third values actually control MTA behavior in any way.
>
>I'm fairly confident at least PP does similar things as well - it would have to
>in order to  support X.400 gatewaying if nothing else.
>  
>
Indeed.
In fact PP translate every SMTP error code to enhanced status code 
internally.

Date: Mon, 06 Aug 2007 22:28:29 -0400
From: John C Klensin <[email-masked]>
To: Ned Freed <[email-masked]>
cc: Jeff Macdonald <[email-masked]>, [email-masked]
Subject: Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463
Sender: [email-masked]

--On Monday, 06 August, 2007 16:03 -0700 Ned Freed
<[email-masked]> wrote:

>...
> But in a compliant implementation there just isn't that much -
> if anything - to change. And while I have some sympathy for
> implementors who in good fairh read  RFC 821 as restricting
> the available status code values, I have ZERO sympathy for
> people who read RFC 1893 this way. At some point we have to
> draw the line and call broken implementation what they are:
> Broken.
>...

In case it isn't clear, I'm in complete agreement with this.  I
was merely trying to point out that such implementations might
exist, no matter how little sympathy reasonable people might
have for them.

You might be feeling more optimistic about the prevalence of
stupidity in the world that I am... today.

     john

From: [email-masked]
Cc: Jeff Macdonald <[email-masked]>, [email-masked], [email-masked]
Date: Mon, 06 Aug 2007 16:03:38 -0700 (PDT)
Subject: Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463
To: John C Klensin <[email-masked]>
Sender: [email-masked]

> --On Saturday, 04 August, 2007 19:09 -0400 Jeff Macdonald
> <[email-masked]> wrote:

> >...
> > John and Ned, you both mentioned 'worth the effort'. Is that
> > because you both believe the RFC wouldn't be an "Independent
> > Submission"? I'm very new to this whole process, so forgive me
> > if this is a stupid question.

> It is certainly not a stupid question.   The question (at least
> my version -- Ned might have a different one) is whether it
> would be worth the trouble for existing server implementations
> to change their code and existing client implementations to
> adapt to the new subseries.   Clearly the latter should fall
> back to "first digit" if they don't recognize the second one or
> what is going on generally, but we've had a lot of nasty
> experiences with implementations that think they know more than
> the specs think they ought to know and that might balk at a new
> subseries.

I see that as an issue for SMTP status codes but not for enhanced status codes.
More specifically, Appendix E of RFC 821 (Theory of Reply Codes) gives lists of
the possible values of the first and second digits of SMTP replies and says
nothing about how new values would ever be defined. It is therefore a
reasonable inference that values not on the list are a protocol error. As for
the third digit, again the text is silent but since there's no list giving all
possible values, merely collections of the codes mentioned in the document, it
is a lot harder to argue that values not given in RFC 821 are an error.

But none of this is the case for exhanced status codes. The specifications
for these are quite clear in regards to extensibility. RFC 1893 said:

   New subject and detail codes will be added over time.  Because the
   number space is large, it is not intended that published status codes
   will ever be redefined or eliminated.  Clients should preserve the
   extensibility of the code space by reporting the general error
   described in the subject sub-code when the specific detail is
   unrecognized.

There just isn't a reasonable way to derive the idea that 5.8.n is an error
from these specifications. The worst case issue I suspect you're going to see
is some sort of "error subject is unknown" message come out, and given the
relative paucity of MUAs that do this sort of interpretation even this is going
to be unusual.

> So the question is whether this change would have enough value
> to tell the community that they should go change things

But in a compliant implementation there just isn't that much - if anything - to
change. And while I have some sympathy for implementors who in good fairh read 
RFC 821 as restricting the available status code values, I have ZERO sympathy
for people who read RFC 1893 this way. At some point we have to draw the line
and call broken implementation what they are: Broken.

> and
> whether the implementer community would believe it has enough
> value to be worth the trouble to make those changes.  I have my
> doubts about both.

My issue is with moving some 7.n codes to 8.m codes. I see no problem with
defining 8 as the place for all future policy codes and putting a bunch of them
in there. 

				Ned

Date: Mon, 6 Aug 2007 19:44:29 +0100
From: Tony Finch <[email-masked]>
To: SM <[email-masked]>
cc: Jeff Macdonald <[email-masked]>, [email-masked]
Subject: Re: Question related to  draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463
Sender: [email-masked]

On Mon, 6 Aug 2007, SM wrote:
>
> One of the advantages of fine-grained codes for content rejection is that it
> is easier for senders to determine why the mail did not go through, e.g.
> malware in message,  attachments prohibited for this email address.

It's a pity that there are no codes for those statuses.

For a longer rant on this topic, see
http://www1.ietf.org/mail-archive/web/ima/current/msg00588.html

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR
MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

From: [email-masked]
Cc: John C Klensin <[email-masked]>, [email-masked], [email-masked]
Date: Mon, 06 Aug 2007 10:08:51 -0700 (PDT)
Subject: Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463
To: Jeff Macdonald <[email-masked]>
Sender: [email-masked]

> On Sat, Aug 04, 2007 at 07:25:14PM -0400, John C Klensin wrote:
> >
> >
> > --On Saturday, 04 August, 2007 19:09 -0400 Jeff Macdonald
> > <[email-masked]> wrote:
> >
> > >...
> > > John and Ned, you both mentioned 'worth the effort'. Is that
> > > because you both believe the RFC wouldn't be an "Independent
> > > Submission"? I'm very new to this whole process, so forgive me
> > > if this is a stupid question.
> >
> > It is certainly not a stupid question.   The question (at least
> > my version -- Ned might have a different one) is whether it
> > would be worth the trouble for existing server implementations
> > to change their code

> I've viewed policy as something that is site specific. Therefore it
> makes sense that policy is configurable by an administrator. At least
> that is the case for me. I use a MTA with a custom sieve
> implementation.

That doesn't really supply a justification for why a code change would be
worth it.

> > and existing client implementations to adapt to the new sub series.

> I'm not aware of any MTAs that pay attention to extended SMTP codes.
> Could you supply some examples?

The MTA I work on (PMDF/SJSMS) has had code to process enhanced status codes in
place for almost a decade. This includes looking at the second and third value
of the status code, althogh to be fair this is only done when gatewaying to
non-SMTP environments. In the SMTP-only world the code is extracted from
responses and copied into DSNs and whatnot, but I don't believe the second and
third values actually control MTA behavior in any way.

I'm fairly confident at least PP does similar things as well - it would have to
in order to  support X.400 gatewaying if nothing else.

But examination and use of enhanced status codes is hardly limited to MTAs -
indeed, while MTAs have reason to find and copy these codes around they
generally don't need to look at their values. The same canont be said for
various other agents such as MUAs wanting to localize DSNs or list managers
wanting to automatically process DSNs. I cannot cite an example of a deployed
MUA that does DSN translation but that doesn't mean there aren't any. As for
list managers, I know of at least two that process enhanced status codes.

As for whether or no the specific coes we're talking about here are ones that
implementations would check for and care about, they don't matter to our code
but they may to other implementations.

> > So the question is whether this change would have enough value
> > to tell the community that they should go change things and
> > whether the implementer community would believe it has enough
> > value to be worth the trouble to make those changes.  I have my
> > doubts about both.

> Depends on which communities we are talking about. I don't think there
> needs to be any server changes. It simple a new set of codes for
> administrators to use when they set their policies.

You're assuming these codes are specified as part of policy settings rather
than there being code to enforce a given policy that returns a hardcoded error
when the policy is violated. We use both approaches in our code and I doubt
very much we're alone in that.

> But I suppose you may be talking about anti-spam black boxes.

And all sorts of other stuff.

				Ned

Date: Mon, 06 Aug 2007 10:16:34 -0700
To: Jeff Macdonald <[email-masked]>
From: SM <[email-masked]>
Subject: Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463
Cc: [email-masked]
Sender: [email-masked]

Hi Jeff,
At 08:22 06-08-2007, Jeff Macdonald wrote:
>I've viewed policy as something that is site specific. Therefore it
>makes sense that policy is configurable by an administrator. At least
>that is the case for me. I use a MTA with a custom sieve
>implementation.

Policy is site specific.  It's not obvious to fit them within 
predefined codes especially when we are dealing with with rejection 
based on content inspection.  Receivers may not wish to provide too 
many details about the rejection as that information may be misused 
by some senders.

One of the advantages of fine-grained codes for content rejection is 
that it is easier for senders to determine why the mail did not go 
through, e.g. malware in message,  attachments prohibited for this 
email address.

Regards,
-sm 

Date: Mon, 6 Aug 2007 11:22:58 -0400
From: Jeff Macdonald <[email-masked]>
To: John C Klensin <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463
Sender: [email-masked]

On Sat, Aug 04, 2007 at 07:25:14PM -0400, John C Klensin wrote:
> 
> 
> --On Saturday, 04 August, 2007 19:09 -0400 Jeff Macdonald
> <[email-masked]> wrote:
> 
> >...
> > John and Ned, you both mentioned 'worth the effort'. Is that
> > because you both believe the RFC wouldn't be an "Independent
> > Submission"? I'm very new to this whole process, so forgive me
> > if this is a stupid question.
> 
> It is certainly not a stupid question.   The question (at least
> my version -- Ned might have a different one) is whether it
> would be worth the trouble for existing server implementations
> to change their code

I've viewed policy as something that is site specific. Therefore it
makes sense that policy is configurable by an administrator. At least
that is the case for me. I use a MTA with a custom sieve
implementation.

> and existing client implementations to adapt to the new sub series.

I'm not aware of any MTAs that pay attention to extended SMTP codes.
Could you supply some examples?

<snip> 

> So the question is whether this change would have enough value
> to tell the community that they should go change things and
> whether the implementer community would believe it has enough
> value to be worth the trouble to make those changes.  I have my
> doubts about both.

Depends on which communities we are talking about. I don't think there
needs to be any server changes. It simple a new set of codes for
administrators to use when they set their policies.

But I suppose you may be talking about anti-spam black boxes.

> Compared to either of those questions, the cost of pushing a
> relatively short and clear document through the IETF system is
> fairly low although I would discourage you from trying unless
> you think the answers to those questions would be "yes, enough
> implementers would believe this is worthwhile to do it if the
> spec were written and approved".

I do. Thanks again.

-- 
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421 
:: v: 781-372-1922 | f: 781-863-8118 
:: www.e-dialog.com

Date: Sat, 04 Aug 2007 19:25:14 -0400
From: John C Klensin <[email-masked]>
To: Jeff Macdonald <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463
Sender: [email-masked]

--On Saturday, 04 August, 2007 19:09 -0400 Jeff Macdonald
<[email-masked]> wrote:

>...
> John and Ned, you both mentioned 'worth the effort'. Is that
> because you both believe the RFC wouldn't be an "Independent
> Submission"? I'm very new to this whole process, so forgive me
> if this is a stupid question.

It is certainly not a stupid question.   The question (at least
my version -- Ned might have a different one) is whether it
would be worth the trouble for existing server implementations
to change their code and existing client implementations to
adapt to the new subseries.   Clearly the latter should fall
back to "first digit" if they don't recognize the second one or
what is going on generally, but we've had a lot of nasty
experiences with implementations that think they know more than
the specs think they ought to know and that might balk at a new
subseries.

So the question is whether this change would have enough value
to tell the community that they should go change things and
whether the implementer community would believe it has enough
value to be worth the trouble to make those changes.  I have my
doubts about both.

Compared to either of those questions, the cost of pushing a
relatively short and clear document through the IETF system is
fairly low although I would discourage you from trying unless
you think the answers to those questions would be "yes, enough
implementers would believe this is worthwhile to do it if the
spec were written and approved".

     john

Date: Sat, 4 Aug 2007 19:09:36 -0400
From: Jeff Macdonald <[email-masked]>
To: John C Klensin <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463
Sender: [email-masked]

On Sat, Aug 04, 2007 at 04:09:57PM -0400, John C Klensin wrote:
> 
> The difficulty, IMO, is that since many of the "policy"
> decisions have been made in practice to provide better security,
> the distinction may not be clear and splitting things into
> multiple codes may do as much to obscure what is going on as to
> clarify it.  As the obvious example, if I reject a message
> because I've concluded that the apparent sender is often a
> source of malware, but without having examined the message
> sufficiently to make a solid determination of whether malware is
> present in it, is that "security" or "policy"?  Conversely, if I
> detect malware as being present and identify it and then reject
> the message, is that "security" or a "policy" of blocking known
> malware at the MTA rather than letting user anti-virus software
> sort it out?

IMO, both examples are policy. Since future codes must be registered,
group consensus would put things in the proper place.
 
> I don't have a major objection to the proposed change, and
> better documentation is always A Good Thing, but, especially
> since there would be no way to tell whether a legacy system
> emitting at 5.7.z code had been upgraded or not, I'm not
> convinced that the benefits of this are worth the effort.

I don't understand the upgrade concern. If x.7.13 isn't widely used the
current meaning could be safely moved to x.8.3. x.7.1 and x.7.2 stay
defined as they are today. x.8.1 and x.8.2 are just the equivalent of
x.7.1 and x.7.2. The RFC would say implementations SHOULD use x.8.1 and
x.8.2 instead of x.7.1 and x.7.2. Perhaps an update could change that
SHOULD to a MUST 10 years from now.

John and Ned, you both mentioned 'worth the effort'. Is that because
you both believe the RFC wouldn't be an "Independent Submission"? I'm
very new to this whole process, so forgive me if this is a stupid
question.

-- 
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421 
:: v: 781-372-1922 | f: 781-863-8118 
:: www.e-dialog.com

Date: Sat, 04 Aug 2007 16:09:57 -0400
From: John C Klensin <[email-masked]>
To: [email-masked], Jeff Macdonald <[email-masked]>
cc: [email-masked]
Subject: Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463
Sender: [email-masked]

--On Saturday, 04 August, 2007 12:26 -0700
[email-masked] wrote:

>> It seems to me that Security and Policy could be separate.
>> Since the majority of the x.7.x codes are security related,
>> it seems logical to dedicate x.7.x to just security. For
>> policy codes, I suggest using a new subject code of 8.
>> Therefore all policy codes would be x.8.x. It would be
>> initially populated with x.7.1, x.7.2 and x.7.13 as x.8.1,
>> x.8.2 and x.8.3 respectively. The current x.7.1 and x.7.2
>> would be kept for legacy reasons. x.7.13 seems newly defined,
>> so I don't believe there would be a legacy issue there.
>> Additional values that seem relevant to policy could be:
> 
> I see no problem doing this, but OTOH I'm not seeing a lot of
> clear benefit to doing it either. The closest I can come is
> that it might be nice to be able to tell the different between
> an unknown policy and unknown security error, that is, making
> a distinction between 5.7.0 and 5.8.0 might be useful in some
> cases.

The difficulty, IMO, is that since many of the "policy"
decisions have been made in practice to provide better security,
the distinction may not be clear and splitting things into
multiple codes may do as much to obscure what is going on as to
clarify it.  As the obvious example, if I reject a message
because I've concluded that the apparent sender is often a
source of malware, but without having examined the message
sufficiently to make a solid determination of whether malware is
present in it, is that "security" or "policy"?  Conversely, if I
detect malware as being present and identify it and then reject
the message, is that "security" or a "policy" of blocking known
malware at the MTA rather than letting user anti-virus software
sort it out?

I don't have a major objection to the proposed change, and
better documentation is always A Good Thing, but, especially
since there would be no way to tell whether a legacy system
emitting at 5.7.z code had been upgraded or not, I'm not
convinced that the benefits of this are worth the effort.

     john

From: [email-masked]
Cc: [email-masked]
Date: Sat, 04 Aug 2007 12:26:18 -0700 (PDT)
Subject: Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463
To: Jeff Macdonald <[email-masked]>
Sender: [email-masked]

> RFC 3463 describes x.7.x as "Security or Policy". It seems only 5.7.1
> and 5.7.2 are policy based while the remainder are security related. In
> draft-hansen-4468upd-mailesc-registry-02.txt  adds x.7.13 as another policy
> related status code.

> It seems to me that Security and Policy could be separate. Since the
> majority of the x.7.x codes are security related, it seems logical to
> dedicate x.7.x to just security. For policy codes, I suggest using a
> new subject code of 8. Therefore all policy codes would be x.8.x. It
> would be initially populated with x.7.1, x.7.2 and x.7.13 as x.8.1,
> x.8.2 and x.8.3 respectively. The current x.7.1 and x.7.2 would be kept
> for legacy reasons. x.7.13 seems newly defined, so I don't believe
> there would be a legacy issue there. Additional values that seem
> relevant to policy could be:

I see no problem doing this, but OTOH I'm not seeing a lot of clear benefit to
doing it either. The closest I can come is that it might be nice to be able to
tell the different between an unknown policy and unknown security error, that
is, making a distinction between 5.7.0 and 5.8.0 might be useful in some cases.

> x.8.4	to many connections
> x.8.5	to many bad recipients
> x.8.6	images not allowed here
> x.8.7	content contains SPAM URL

> etc

> basically the x.8.x codes would try to break out all the different
> meanings that 5.7.1 has been used to indicate many different types of
> policy.

> By separating policy and security, one could simplify coding logic to a
> level where any x.8.x code is policy related (plus x.7.1 and x.7.2).

> I'd like to author a RFC that is specific to just policy codes. Any
> feedback is greatly appreciated.

Having additional clearly defined codes is always a good thing IMO so I fully
support the creation of such a document, regardless of whether it elaborates
new 7.x codes or creates splits out policy codes into a new group.

				Ned

Date: Fri, 3 Aug 2007 23:42:21 -0400
From: Jeff Macdonald <[email-masked]>
To: [email-masked]
Subject: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463
Sender: [email-masked]

RFC 3463 describes x.7.x as "Security or Policy". It seems only 5.7.1
and 5.7.2 are policy based while the remainder are security related. In
draft-hansen-4468upd-mailesc-registry-02.txt  adds x.7.13 as another policy
related status code.

It seems to me that Security and Policy could be separate. Since the
majority of the x.7.x codes are security related, it seems logical to
dedicate x.7.x to just security. For policy codes, I suggest using a
new subject code of 8. Therefore all policy codes would be x.8.x. It
would be initially populated with x.7.1, x.7.2 and x.7.13 as x.8.1,
x.8.2 and x.8.3 respectively. The current x.7.1 and x.7.2 would be kept
for legacy reasons. x.7.13 seems newly defined, so I don't believe
there would be a legacy issue there. Additional values that seem
relevant to policy could be:

x.8.4	to many connections
x.8.5	to many bad recipients
x.8.6	images not allowed here
x.8.7	content contains SPAM URL

etc

basically the x.8.x codes would try to break out all the different
meanings that 5.7.1 has been used to indicate many different types of
policy.

By separating policy and security, one could simplify coding logic to a
level where any x.8.x code is policy related (plus x.7.1 and x.7.2).

I'd like to author a RFC that is specific to just policy codes. Any
feedback is greatly appreciated.

-- 
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421 
:: v: 781-372-1922 | f: 781-863-8118 
:: www.e-dialog.com