Jeff Macdonald | 4 Aug 05:42 2007

Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463


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).

(Continue reading)

ned+ietf-smtp | 4 Aug 21:26 2007

Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463


> 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
(Continue reading)

John C Klensin | 4 Aug 22:09 2007

Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463


--On Saturday, 04 August, 2007 12:26 -0700
ned+ietf-smtp <at> mrochek.com 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
(Continue reading)

Jeff Macdonald | 5 Aug 01:09 2007

Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463


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
(Continue reading)

John C Klensin | 5 Aug 01:25 2007

Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463


--On Saturday, 04 August, 2007 19:09 -0400 Jeff Macdonald
<jmacdonald <at> e-dialog.com> 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
(Continue reading)

Jeff Macdonald | 6 Aug 17:22 2007

Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463


On Sat, Aug 04, 2007 at 07:25:14PM -0400, John C Klensin wrote:
> 
> 
> --On Saturday, 04 August, 2007 19:09 -0400 Jeff Macdonald
> <jmacdonald <at> e-dialog.com> 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> 
(Continue reading)

SM | 6 Aug 19:16 2007
Picon

Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463


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 

ned+ietf-smtp | 6 Aug 19:08 2007

Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463


> On Sat, Aug 04, 2007 at 07:25:14PM -0400, John C Klensin wrote:
> >
> >
> > --On Saturday, 04 August, 2007 19:09 -0400 Jeff Macdonald
> > <jmacdonald <at> e-dialog.com> 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?
(Continue reading)

Tony Finch | 6 Aug 20:44 2007
Picon

Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463


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  <dot <at> dotat.at>  http://dotat.at/
IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR
MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

ned+ietf-smtp | 7 Aug 01:03 2007

Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463


> --On Saturday, 04 August, 2007 19:09 -0400 Jeff Macdonald
> <jmacdonald <at> e-dialog.com> 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.

(Continue reading)


Gmane