Subject: Re: SMTP QoS
From: Julian Onions <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: [email-masked]
Date: Fri, 29 Jun 2001 15:50:27 BST
List-Id: <ietf-smtp.imc.org>

> 
> At 02:28 PM 6/27/2001, [email-masked] wrote:
> >  The statement was that it would go unused.
> >That's demonstrably false.
> >
> >The bottom line is that I think this is one of those things that the world
> >wants. (Needs is another matter.) So if we specify a priority mechanism that
's
> >reasonable and implementable it will deploy rapidly and widely.
> 
> 
> 1.      As stated, the option leaves senders with an incentive to always 
> set high priority.  It costs them nothing to do this.  As we have seen with 
> spammers, some substantial portion of the community will in fact abuse the 
> option, thereby rendering useless.  Some of you believe that human behavior 
> will be different from this projection; please explain.

It will only be any use if the MTA acts on it. I can already set these
sorts of things using UA's. Outlook Express allows me to flag messages
I post as High Priority. It does this by inserting its own header
field 
X-MSMail-Priority: High
so obviously the need is out there. I doubt any MTA, except maybe
Microsofts will act on this particular field. If it used a standard
mechanism I think it would have a better chance. There is already a standard
priority field defined by MIXER actually, but priority is really an
envelope thing. 
This is why I think it is best considered per hop. As you then don't
get the users view of priority, but the view of an MTA that you may trust. 

> 2.      References to usage of SMTP Auth with this option are confusing, 
> since it is used for posting, not relaying.  I'd appreciate clarification 
> to this point.

I think SMTP AUTH is a small part of general auth. You might use it on
submission to allow priority setting, but in general an MTA would use
whatever mechanisms it wished to decide to honor the request. Other
things, like IP address, SSL/TLS etc would also likely factor into the
equation.

As I keep reiterating, whilst an MTA is unlikely to take notice of a
request to do priority=high processing from joe-average-mta, it may
well take note of priority=low processing. There seems little to lose
in doing this.

> 3.      The proposal presumes that a simple rank-ordering approach, by 
> priority, is an appropriate queuing model for global Internet mail 
> relays.  To the extent that the proposal attempts less than that -- for 
> example, simply trying to provide an advisory that each relay will use in 
> whatever way that it feels appropriate -- then it does little more than 
> substantiate the send-and-pray view of Internet mail.  Users will have no 
> basis for knowing what to expect from the relay path.  The purpose of QoS 
> mechanisms is to increase predictability.  This will not achieve that.

It provides a mechanism for one MTA to tell another what it thinks the
priority of this message is in comparison to others it has. If you
mandate processing of priority, implementations will ignore it based
on your arguments in 1), so it seemed prudent to allow them that
latitude. You can currently do the send-and-pray technique by setting
various header fields that may or may not be recognised. I think this
mechanism is a step forward from that. My setting in Outlook Express
is exactly this (though I think in that case it is probably better
considered importance than priority).

I doubt there is any way I could convince your MTA to give my messages
high priority processing without some agreement before hand. But I might
convince it to do low priority from distribution list messages.

> 4.      The IETF does not do intranet standards.  This option looks quite 
> reasonable for use within a single administrative domain, where system-wide 
> handling policies can be established AND enforced.  For the global 
> Internet, the Force is very much against successful operation.

This is starting to get into shades of grey. Isn't AUTH an intranet
solution? For that matter POP and IMAP too? They only work if there is
an agreement already in place amongst a closed community.

I see two ways of passing priority information. As a hint (as in this
draft) which given communities may respect; or passing it, together with
sufficient other information, that an MTA can independantly validate to
its satisfaction that this message was and is suitable to be processed
at the given priority.  The second strikes me as so heavy weight no
one will implement it much, even if it can be specified in a
reasonable way.

The military people would be happy with the first, they would just
have a policy that you MUST take the hint. Some internet MTAs will be
happy to demote low priority requests too. In certain circumstances
they may honor high priority too (consider two large companies that
exchange mail and want to allow priority processing to occur between
their management). 

Julian.

Date: Fri, 29 Jun 2001 07:16:54 -0700 (PDT)
From: [email-masked]
Subject: Re: SMTP QoS
To: Dave Crocker <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> 1.      As stated, the option leaves senders with an incentive to always
> set high priority.  It costs them nothing to do this.  As we have seen with
> spammers, some substantial portion of the community will in fact abuse the
> option, thereby rendering useless.  Some of you believe that human behavior
> will be different from this projection; please explain.

Even if you assume this is true (past experience with priority facilities
indicates it is not), this ignores the need to lower as well as raise
priority. The single most widely deployed priority mechanism today,
the precedence, only provides a way to lower priority from the normal
level, not raise it. And this it is widely used for this purpose (among
others).

> 2.      References to usage of SMTP Auth with this option are confusing,
> since it is used for posting, not relaying.  I'd appreciate clarification
> to this point.

Read the spec. SMTP AUTH not only provides facility for posting, it also
provides facilities for relaying authentication credentials.

> 3.      The proposal presumes that a simple rank-ordering approach, by
> priority, is an appropriate queuing model for global Internet mail
> relays.  To the extent that the proposal attempts less than that -- for
> example, simply trying to provide an advisory that each relay will use in
> whatever way that it feels appropriate -- then it does little more than
> substantiate the send-and-pray view of Internet mail.  Users will have no
> basis for knowing what to expect from the relay path.  The purpose of QoS
> mechanisms is to increase predictability.  This will not achieve that.

I have no clear idea what "increase predictability" means, but I'm pretty
sure that nobody views priority as a means to achieve that end.

> 4.      The IETF does not do intranet standards.  This option looks quite
> reasonable for use within a single administrative domain, where system-wide
> handling policies can be established AND enforced.  For the global
> Internet, the Force is very much against successful operation.

Actually, the IETF does intranet standards all the time. This is especially
true if you equate administrative domains with intranets. By this rule POP3,
IMAP4 and SMTP submit are all intranet protocols that don't scale to the entire
Internet.

And as I pointed out above, even if you accept the notion that priority is only
useful in conjunction with authentication (I think authentication adds
considerable value but isn't required in some scenarios), the authentication
relay model that's very much a part of SMTP AUTH means it can be extended
past the boundaries of a single administative domain.

				Ned

To: Dave Crocker <[email-masked]>
Cc: [email-masked]
Subject: Re: SMTP QoS 
From: [email-masked]
Date: Fri, 29 Jun 2001 09:54:33 -0400
Sender: [email-masked]

--==_Exmh_548197417P
Content-Type: text/plain; charset=us-ascii

On Fri, 29 Jun 2001 07:52:23 EDT, Dave Crocker <[email-masked]>  said:

> 4.      The IETF does not do intranet standards.  This option looks quite 
> reasonable for use within a single administrative domain, where system-wide 
> handling policies can be established AND enforced.  For the global 
> Internet, the Force is very much against successful operation.

Ah.  A good point indeed.

Would you favor/suggest that this be re-cast as an option for message
posting?  That way, we'd at least have a standard way for MUAs on the
desktop to talk to the MTA on the mail hub. We've had pretty good sucess
at educating our users that "XYZ works only on campus" for many values
of XYZ, so this would not be a surprise to our users.

The specific application I'm thinking of is that there are a "very small"
(for a 60K mailbox environment) number of people that we'd *like* to be
able to *occasionally* submit mail at 'high priority' so it gets delivered
quickly.  However, we need a way to identify 'important' notices...
-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

--==_Exmh_548197417P
Content-Type: application/pgp-signature

--==_Exmh_548197417P--

Date: Fri, 29 Jun 2001 07:52:23 -0400
To: [email-masked]
From: Dave Crocker <[email-masked]>
Subject: Re: SMTP QoS
Sender: [email-masked]

At 02:28 PM 6/27/2001, [email-masked] wrote:
>  The statement was that it would go unused.
>That's demonstrably false.
>
>The bottom line is that I think this is one of those things that the world
>wants. (Needs is another matter.) So if we specify a priority mechanism that's
>reasonable and implementable it will deploy rapidly and widely.

1.      As stated, the option leaves senders with an incentive to always 
set high priority.  It costs them nothing to do this.  As we have seen with 
spammers, some substantial portion of the community will in fact abuse the 
option, thereby rendering useless.  Some of you believe that human behavior 
will be different from this projection; please explain.

2.      References to usage of SMTP Auth with this option are confusing, 
since it is used for posting, not relaying.  I'd appreciate clarification 
to this point.

3.      The proposal presumes that a simple rank-ordering approach, by 
priority, is an appropriate queuing model for global Internet mail 
relays.  To the extent that the proposal attempts less than that -- for 
example, simply trying to provide an advisory that each relay will use in 
whatever way that it feels appropriate -- then it does little more than 
substantiate the send-and-pray view of Internet mail.  Users will have no 
basis for knowing what to expect from the relay path.  The purpose of QoS 
mechanisms is to increase predictability.  This will not achieve that.

4.      The IETF does not do intranet standards.  This option looks quite 
reasonable for use within a single administrative domain, where system-wide 
handling policies can be established AND enforced.  For the global 
Internet, the Force is very much against successful operation.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

Date: Thu, 28 Jun 2001 20:14:53 -0700 (PDT)
From: [email-masked]
Subject: RE: IANA SMTP registry
To: Blake Ramsdell <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

> So far, the only comment has been "the Sendmail extensions shouldn't be
> listed", which makes it sound like I'm not completely nuts, so I'm going to
> press on.

Your assessment of the situation was IMO correct.

> I think that most of the comments that I've presented here are valid.  Who
> maintains the document that I mentioned, and how does it go about being
> updated?

This is already being taken care of. A number of changes, including but
not limited to the ones you pointed out, are in progress now.

> I can certainly create a draft, as I've recently spent a lot of time
> researching this.

There should be no need to do this.

				Ned

Date: Thu, 28 Jun 2001 16:43:55 -0700
To: "Blake Ramsdell" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: IANA SMTP registry
Sender: [email-masked]

At 3:35 PM -0700 6/28/01, Blake Ramsdell wrote:
>I think that most of the comments that I've presented here are valid.  Who
>maintains the document that I mentioned, and how does it go about being
>updated?

IANA maintains it. Send a message to [email-masked] describing the 
problem and your proposed solution. You might want to mention that it 
has been discussed on this list.

>I can certainly create a draft, as I've recently spent a lot of time
>researching this.

No need to write a draft; it is an IANA registry.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: IANA SMTP registry
Date: Thu, 28 Jun 2001 15:35:04 -0700
Sender: [email-masked]

So far, the only comment has been "the Sendmail extensions shouldn't be
listed", which makes it sound like I'm not completely nuts, so I'm going to
press on.

I think that most of the comments that I've presented here are valid.  Who
maintains the document that I mentioned, and how does it go about being
updated?

I can certainly create a draft, as I've recently spent a lot of time
researching this.

Blake

-----Original Message-----
From: Blake Ramsdell 
Sent: Sunday, June 24, 2001 5:51 PM
To: [email-masked]'
Subject: IANA SMTP registry

My understanding is that: 

http://www.isi.edu/in-notes/iana/assignments/mail-parameters 

should have all of the SMTP service extensions listed (RFC2821 section
2.2.2)

1. The AUTH EHLO keyword and AUTH verb are not listed (RFC2554 Section 3) 

2. The TCP VIA link type is not listed (RFC2821 Section 4.4) 

3. Should references to RFCs 821 and 822 to be updated to 2821 and 2822? 

4. The keywords VERB and ONEX have "Eric Allman" listed as a reference, but
I have no idea how to dereference it (yes, I know who Allman is and I can
scrounge up his email address, but isn't the spirit of this to be able to
have a publicly available specification, more specifically, an RFC?)

I don't know who to send these to, so this is both a sanity check (the
things I point out may not be things that are required to be in the
registry, though it would be nice to have all of the EHLO keywords
somewhere, and I presume that was the spirit of this page), and a "who
should I send this to?" message.

Blake

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: Keith Moore <[email-masked]>, Julian Onions <[email-masked]>, John C Klensin <[email-masked]>, [email-masked]
Subject: Re: SMTP Service Extension for Priority 
Date: Wed, 27 Jun 2001 15:58:10 -0400
Sender: [email-masked]

I'll have to look at the AUTH parameter again to see whether I think it
would work for this purpose.  It would be nice if it did.

I do think that people aren't terribly likely to use per-recipient
priority settings.  It's not that they're not useful, but they would
clutter up the user interface.

Keith

Date: Wed, 27 Jun 2001 12:09:23 -0700 (PDT)
From: [email-masked]
Subject: Re: SMTP Service Extension for Priority
To: Keith Moore <[email-masked]>
Cc: [email-masked], Keith Moore <[email-masked]>, Julian Onions <[email-masked]>, John C Klensin <[email-masked]>, [email-masked]
Sender: [email-masked]

> > > yeah, it's a tradeoff.  priority is definitely an MTA function, and for
> > > the past few years we've been fairly strict about requiring that MTA
> > > protocol be transmitted in SMTP.  also, if a message is resent then
> > > it will keep the same headers but should not necessarily keep the same
> > > priority.
> >
> > Not necessarily, but it may make sense as a default. So this could argue
> > for a header field rather than against.

> well, it forces MTAs to look at the message header, and IMHO we shouldn't
> encourage this.  but most do it anyway...

> the purist in me doesn't like it. the pragmatist in me is almost
> ambivalent about it.

The purist in me doesn't like it either, but the pragmatist is way way way
in favor of a new header field.

> but if we accept that priority requires some kind of authenticaiton by
> the sender, I do think it's in some sense cleaner if we get both the
> authentication and the priority setting from the same protocol.
> and I don't see how we can transmit the sender's authentication for
> priority to servers other than the first hop  without an SMTP extension
> anyway.  in other words, for submission SMTP AUTH might be sufficient,
> but for relaying the sender's credentials to subsequent MTAs we're
> going to need something new.

I'm not sure it is a good idea, but we could use the AUTH parameter stuff for
this. (In other words, we already have a mechanism for conveying
authrization information across multiple hops.)

> > (2) Don't split and process the recipients at the lower of the two priorities.

> surely that would violate the notion that higher priority messages should
> be treated as least as favorably as lower priority ones.
 
Look at the phrasing you just used. You talked about higher priority
*messages*, not *recipients*. I could easily argue that the priority of the
*message* is that of the lowest priority recipient. Or the highest. Or an
average.

Regardless of how you word this, aren't people going to think of this in terms
of message priority, not recipient priority? And what's the interface for
setting per-recipient priorities going to look like?

> > And remember that when mapping to systems that only support per-message
> > priority you'd be forced to split to retain the right semantics.

> not clear.  I think you could also comply by just giving the message
> the same priority as that of the higest recipient.

Not when other semantics are conveyed by priority setting, as they sometimes
are in other environments.

				Ned

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: Keith Moore <[email-masked]>, Julian Onions <[email-masked]>, John C Klensin <[email-masked]>, [email-masked]
Subject: Re: SMTP Service Extension for Priority 
Date: Wed, 27 Jun 2001 15:08:01 -0400
Sender: [email-masked]

> > yeah, it's a tradeoff.  priority is definitely an MTA function, and for
> > the past few years we've been fairly strict about requiring that MTA
> > protocol be transmitted in SMTP.  also, if a message is resent then
> > it will keep the same headers but should not necessarily keep the same
> > priority.
> 
> Not necessarily, but it may make sense as a default. So this could argue
> for a header field rather than against.

well, it forces MTAs to look at the message header, and IMHO we shouldn't
encourage this.  but most do it anyway...

the purist in me doesn't like it. the pragmatist in me is almost
ambivalent about it.

but if we accept that priority requires some kind of authenticaiton by
the sender, I do think it's in some sense cleaner if we get both the 
authentication and the priority setting from the same protocol.  
and I don't see how we can transmit the sender's authentication for 
priority to servers other than the first hop  without an SMTP extension 
anyway.  in other words, for submission SMTP AUTH might be sufficient,
but for relaying the sender's credentials to subsequent MTAs we're
going to need something new.

> > the other point that comes to mind is that if a UA doesn't submit
> > a message via SMTP (or SUBMISSION) then it doesn't have a good way to
> > set delivery priority unless it's via a message header.
> 
> Yes, and this proved to be a significant obstacle to actual use of NOTARY.
> Indeed, several MUAs switched to using SMTP for submission because they got
> tired of waiting for other submission mechanisms to be extended.

this might be construed as a feature, particularly if they use PIPELINING.

> > > Additionally, given that MTAs try to avoid splitting messages, it 
> > > isn't at all clear how to handle the case of two recipients with 
> > > different priorities that are travelling together. At a minimum 
> > > some guidelines need to be given for this case.
> 
> > I'm not sure how this is very different than an MTA that tries to relay
> > a message to two recipients at the same server (or at different servers),
> > and RCPT gets a 200 reply for one recipient and a 400 reply for another.
> > The message doesn't get "split" but one recipient in the envelope
> > is marked as delivered and another one is marked "try again later".
> 
> I think you're missing my point. Suppose I have two recipients, [email-masked]
> at priority 1 and [email-masked] at priority 99. I could handle this in a variety
> of ways:
> 
> (1) Split and process the two recipients independently. But this is wasteful
>     of resources. 

right.

> (2) Don't split and process the recipients at the lower of the two priorities.

surely that would violate the notion that higher priority messages should
be treated as least as favorably as lower priority ones.
 
> (3) Don't split and process the recipients at the higher of the two 
> priorities.

that works.  nothing requires the MTA to give the lower priority recipient
pessimal treatment.

> (4) Don't split and process the recipients at the average of the two
>     priorities.

that also violates the notion that higher priority messages should
be treated as least as favorably as lower priority ones.

> (5) Don't split initially and retry at the rates implied by both priorities,
>     but split if the retry was one only intended to get the high priority
>     recipient delivered.

that could also work.
 
> I'm sure many other variations are possible as well.
> 
> > And I don't think there's any requirement that messages with lower priority
> > be given worse treatment than a message with high priority.  So an MTA
> > that treated every recipient as if it had the priority of the 
> > highest-priority recipient in that envelope would still be conforming 
> > (if somewhat pessimal). Certainly if I could relay the message to 
> > other lower priority recipients in the same transaction as a higher 
> > priority recipient, I'd do that.
> 
> That's certainly the way I'd implement it. But I suspect others would 
> disagree.

so if you're still arguing that the document needs to give advice to 
implementors, I strongly agree.

> And remember that when mapping to systems that only support per-message
> priority you'd be forced to split to retain the right semantics.

not clear.  I think you could also comply by just giving the message 
the same priority as that of the higest recipient.

Keith

Date: Wed, 27 Jun 2001 11:34:14 -0700 (PDT)
From: [email-masked]
Subject: Re: SMTP Service Extension for Priority
To: Keith Moore <[email-masked]>
Cc: [email-masked], Keith Moore <[email-masked]>, Julian Onions <[email-masked]>, John C Klensin <[email-masked]>, [email-masked]
Sender: [email-masked]

> > Hmm. Doesn't this argue that an SMTP extension is the wrong mechanism?
> > A priority specification can be propogated in a header field end to end
> > even if intermediate MTAs don't support it. If you use an extension for
> > this all the intermediaries have to support it.

> yeah, it's a tradeoff.  priority is definitely an MTA function, and for
> the past few years we've been fairly strict about requiring that MTA
> protocol be transmitted in SMTP.  also, if a message is resent then
> it will keep the same headers but should not necessarily keep the same
> priority.

Not necessarily, but it may make sense as a default. So this could argue
for a header field rather than against.

> > The counter is that in order for this to be recipient-specific it has to
> > be an SMTP extension.

> and that's another point.

> the other point that comes to mind is that if a UA doesn't submit
> a message via SMTP (or SUBMISSION) then it doesn't have a good way to
> set delivery priority unless it's via a message header.

Yes, and this proved to be a significant obstacle to actual use of NOTARY.
Indeed, several MUAs switched to using SMTP for submission because they got
tired of waiting for other submission mechanisms to be extended.

> > > and if the purpose of priority is to make better use of limited resources
> > > then you want to be able to set it on a per-message basis, not have it
> > > derived from the sender or recipient address and MTA-local rules.

> > Additionally, given that MTAs try to avoid splitting messages, it isn't at all
> > clear how to handle the case of two recipients with different priorities that
> > are travelling together. At a minimum some guidelines need to be given for
> > this case.

> I'm not sure how this is very different than an MTA that tries to relay
> a message to two recipients at the same server (or at different servers),
> and RCPT gets a 200 reply for one recipient and a 400 reply for another.
> The message doesn't get "split" but one recipient in the envelope
> is marked as delivered and another one is marked "try again later".

I think you're missing my point. Suppose I have two recipients, [email-masked]
at priority 1 and [email-masked] at priority 99. I could handle this in a variety
of ways:

(1) Split and process the two recipients independently. But this is wasteful
    of resources. Additionally, it may lead to unnecessary violations of the
    astonishment principle. Suppose I implement retries for different
    priorities differently, 1 gets retried every hour and 99 gets retried
    every 10 minutes, and they aren't synchronized. But suppose the d.com is
    down and happens to come back up for just an instant just as the hourly
    retry occurs.

(2) Don't split and process the recipients at the lower of the two priorities.

(3) Don't split and process the recipients at the higher of the two priorities.

(4) Don't split and process the recipients at the average of the two
    priorities.
    
(5) Don't split initially and retry at the rates implied by both priorities,
    but split if the retry was one only intended to get the high priority
    recipient delivered.

I'm sure many other variations are possible as well.

> And I don't think there's any requirement that messages with lower priority
> be given worse treatment than a message with high priority.  So an MTA
> that treated every recipient as if it had the priority of the highest-priority
> recipient in that envelope would still be conforming (if somewhat pessimal).
> Certainly if I could relay the message to other lower priority recipients
> in the same transaction as a higher priority recipient, I'd do that.

That's certainly the way I'd implement it. But I suspect others would disagree.
And remember that when mapping to systems that only support per-message
priority you'd be forced to split to retain the right semantics.

				Ned

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: Keith Moore <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: SMTP QoS 
Date: Wed, 27 Jun 2001 14:43:10 -0400
Sender: [email-masked]

> So if we specify a priority mechanism that's
> reasonable and implementable it will deploy rapidly and widely.

probably so.  the real trick is to specify it in such a way that
it doesn't tend to block delivery of other mail.

(in other words, one of the problems with a priority queueing system
is that naive implementations tend to starve tasks with lower priority -
and many MTAs have naive queueing systems)

Date: Wed, 27 Jun 2001 11:28:11 -0700 (PDT)
From: [email-masked]
Subject: Re: SMTP QoS
To: Keith Moore <[email-masked]>
Cc: [email-masked], Dave Crocker <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked]
Sender: [email-masked]

> > > We have a 30+ year history that an inadequately specified "priority" field
> > > will go unused.
> >
> > Actually we have exactly the opposite. We have at least two inadequately
> > specified QoS mechanisms for email already (priority and precedence header
> > fields), and both of them are in wide use.

> I suspect the point is not really that they will go *entirely* unused, but
> that a poorly specified priority mechanism will not be very useful overall,
> and so will not be *widely* used in comparison to the scope of Internet
> mail. Stated that way, I'd have to agree.

But that's not what was stated. The statement was that it would go unused.
That's demonstrably false. We may quibble about the level of usage, but it is
certainly nonnegligable, and that sufficies to disprove the point.

The bottom line is that I think this is one of those things that the world
wants. (Needs is another matter.) So if we specify a priority mechanism that's
reasonable and implementable it will deploy rapidly and widely.

				Ned

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: Dave Crocker <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: SMTP QoS 
Date: Wed, 27 Jun 2001 14:01:11 -0400
Sender: [email-masked]

> > We have a 30+ year history that an inadequately specified "priority" field
> > will go unused.
> 
> Actually we have exactly the opposite. We have at least two inadequately
> specified QoS mechanisms for email already (priority and precedence header
> fields), and both of them are in wide use. 

I suspect the point is not really that they will go *entirely* unused, but
that a poorly specified priority mechanism will not be very useful overall,
and so will not be *widely* used in comparison to the scope of Internet 
mail. Stated that way, I'd have to agree.

Keith

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: Keith Moore <[email-masked]>, Julian Onions <[email-masked]>, John C Klensin <[email-masked]>, [email-masked]
Subject: Re: SMTP Service Extension for Priority 
Date: Wed, 27 Jun 2001 13:42:16 -0400
Sender: [email-masked]

> Hmm. Doesn't this argue that an SMTP extension is the wrong mechanism?
> A priority specification can be propogated in a header field end to end
> even if intermediate MTAs don't support it. If you use an extension for
> this all the intermediaries have to support it.

yeah, it's a tradeoff.  priority is definitely an MTA function, and for 
the past few years we've been fairly strict about requiring that MTA
protocol be transmitted in SMTP.  also, if a message is resent then 
it will keep the same headers but should not necessarily keep the same
priority.

> The counter is that in order for this to be recipient-specific it has to
> be an SMTP extension. 

and that's another point.

the other point that comes to mind is that if a UA doesn't submit
a message via SMTP (or SUBMISSION) then it doesn't have a good way to
set delivery priority unless it's via a message header.

> > and if the purpose of priority is to make better use of limited resources
> > then you want to be able to set it on a per-message basis, not have it
> > derived from the sender or recipient address and MTA-local rules.
> 
> Additionally, given that MTAs try to avoid splitting messages, it isn't at all
> clear how to handle the case of two recipients with different priorities that
> are travelling together. At a minimum some guidelines need to be given for
> this case.

I'm not sure how this is very different than an MTA that tries to relay
a message to two recipients at the same server (or at different servers), 
and RCPT gets a 200 reply for one recipient and a 400 reply for another. 
The message doesn't get "split" but one recipient in the envelope
is marked as delivered and another one is marked "try again later".

And I don't think there's any requirement that messages with lower priority
be given worse treatment than a message with high priority.  So an MTA
that treated every recipient as if it had the priority of the highest-priority
recipient in that envelope would still be conforming (if somewhat pessimal).  
Certainly if I could relay the message to other lower priority recipients 
in the same transaction as a higher priority recipient, I'd do that.

Keith

Date: Wed, 27 Jun 2001 09:45:14 -0700 (PDT)
From: [email-masked]
Subject: Re: SMTP Service Extension for Priority
To: Keith Moore <[email-masked]>
Cc: Julian Onions <[email-masked]>, Keith Moore <[email-masked]>, John C Klensin <[email-masked]>, [email-masked]
Sender: [email-masked]

> > "An MTA that accepts the priority property, will ensure that messages
> > marked with higher priority received from the same MTA are treated
> > with the same, or higher, priority for scheduling purposes"

> no, I don't think this is a good idea.

> in fact, I think the whole idea of having the queuing priority affected
> by preceding MTAs is severely flawed.  for instance, the choke point
> might be closer to the receiver than the sender - and yet the sender
> might have privileges to set priority on the MTAs close to the receiver.
> why should the earlier MTAs dilute the sender's priority?

Exactly. I see priority as an attribute of the message. Whether or not a given
MTA choses to honor it doesn't affect the attribute itself.

> > I think you are mixing a couple of concepts here. I see priority as a
> > dynamic quantity, therefore it is really only useful from one MTA to
> > another. It should not be tied to the user, other than at submission time.

> I think it's just the opposite.  Other than in a completely closed system,
> there will inherently be some users who have permission to set message
> priority and some who do not.

I agree. There should be an effective priority computed by an MTA, possibly
based on the priority suggested by the sender and possibly not, but this isn't
something that gets propogated as part of the message.

> > A user might start out requesting high priority, it hits the
> > submission MTA(A). Based on local knowledge and rule processing, it
> > asserts that in reality, this user is only allowed to request priority
> > level 25 or below, so it downgrades it internally, sorts
> > its queues appropriately.

> the problem is, MTA A doesn't know what permissions the user has with
> MTA B, or with the MTAs nearer to the recipient.

Exactly. Downgrading the priority internally is fine, but it doesn't
change the value of the priority attribute of the message.

> > I dont see a chain of trust being useful either

> well, that's pretty much what you were describing.  but I've since
> convinced myself that it's not the way to go.

Agreed.

> > Message submitted to MTA(A) with priority HIGH,
> > passed to MTA(B) which doesn't trust MTA(A). It ignores the parameter,
> > and passes the message onwards to MTA(C) with no priority
> > parameter. MTA(C) using local rules, determines that the recipient of
> > the message has payed extra for priority processing, so assigns the
> > message a given priority (say, 33). It can then pass this on to
> > another MTA saying effectively I would like you to treat this message
> > with priority 33, if you trust my judgement.

> that's silly.  if MTA C can decide the message's priority in the absence
> of any input from the sender, then we don't need the priority extension
> at all.  if priority is to be very useful, it needs to be preserved
> end-to-end.  intermediate MTAs can ignore it, but they shouldn't try to
> change it, because that's misrepresenting the sender's request.
> that doesn't preclude an MTA giving better service to some recipients
> over others, but recipient-derived priority should be independent from
> the sender-requested priority.

Hmm. Doesn't this argue that an SMTP extension is the wrong mechanism?
A priority specification can be propogated in a header field end to end
even if intermediate MTAs don't support it. If you use an extension for
this all the intermediaries have to support it.

The counter is that in order for this to be recipient-specific it has to
be an SMTP extension. So that's the tradeoff -- a recipient-specific
mechanism that requires upgrading intermediaries to work, or a
message-specific mechanism that requires no upgrading.

> and if the purpose of priority is to make better use of limited resources
> then you want to be able to set it on a per-message basis, not have it
> derived from the sender or recipient address and MTA-local rules.

Additionally, given that MTAs try to avoid splitting messages, it isn't at all
clear how to handle the case of two recipients with different priorities that
are travelling together. At a minimum some guidelines need to be given for this
case.

				Ned

Date: Wed, 27 Jun 2001 09:09:40 -0700 (PDT)
From: [email-masked]
Subject: Re: SMTP QoS
To: Dave Crocker <[email-masked]>
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Sender: [email-masked]

> At 10:40 AM 6/26/2001, Arnt Gulbrandsen wrote:
> >I venture to guess that people will drop max-priority mail because so much
> >of it is spam, just like people now drop mail from <>.

> The proposal for a priority bit is an attempt to provide a degree of
> quality of service.

> We have a 30+ year history that an inadequately specified "priority" field
> will go unused.

Actually we have exactly the opposite. We have at least two inadequately
specified QoS mechanisms for email already (priority and precedence header
fields), and both of them are in wide use. Support isn't universal by any
means, but it definitely is widespread. Had there been a standard 10 years ago
I suspect support for these really would be universal at this point.

> Take a look at arpanet/internet level packet
> switching.  The last 6 years of work on IPv6 shows that trying to provide
> useful QoS is quite difficult.

The differing time regimes makes this a very different problem, so I'm not sure
you can extrapolate from it.

> As noted by others, without the rest of the total system specification, the
> priority field will be mis-used by a variety of senders.  This will
> guarantee that it be ignored by relays.

The existing ad-hoc fields are misused, but not enough to make relays
universally ignore them.

				Ned

Date: Wed, 27 Jun 2001 11:47:22 -0400
From: John C Klensin <[email-masked]>
Subject: Re: SMTP Service Extension for Priority
To: Julian Onions <[email-masked]>
Cc: Keith Moore <[email-masked]>, [email-masked]
Sender: [email-masked]

--On Wednesday, 27 June, 2001 08:41 +0100 Julian Onions
<[email-masked]> wrote:

> OK - so would expanding the security section help? I don't
> want to be prescriptive, as there are a lot of different cases
> that might make sense. But a discussion on what an implementor
> might want to consider for various possible cases could be
> included there. Is that the sort of thing you are after? 
> If so - I'll draft some text and send it out.

This is certainly necessary.  Whether it is sufficient is
another matter.

> Ummm - I think you lost me here... I'm not sure what you are
> asking or suggesting. The extension is meant to be used on a
> hop by hop basis, and should be used regardless of what the
> hop type is. Is there some similar extension that does this
> that I could refer to. In my mind, this draft shares a lot of
> common ground with the SIZE extension.

The difference is that, with SIZE, the authority of each
receiving MTA to determine what it will accept is unquestioned.
As Keith indicates, authorization for changing priorities, or
changing intermediate handling based on them, is not obvious.

   john

Date: Wed, 27 Jun 2001 09:10:55 -0500
To: "Koti" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Need info about BASE64 encoding & BASE64 decoding
Cc: <[email-masked]>
Sender: [email-masked]

On 6/27/01 at 4:46 PM +0530, Koti wrote:

>Is there any specific BASE64 algoritham ?
>Where can i get more info about BASE64 algoritham?

RFC 2045, section 6.8.

Many of the questions you are asking are simply answered by reading 
the relevant RFCs. You might want to look at <http://www.imc.org/> 
and take a look at their section on Internet mail standards.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: Keith Moore <[email-masked]>
To: Julian Onions <[email-masked]>
cc: Keith Moore <[email-masked]>, John C Klensin <[email-masked]>, [email-masked]
Subject: Re: SMTP Service Extension for Priority 
Date: Wed, 27 Jun 2001 10:03:22 -0400
Sender: [email-masked]

> > 1. a set of rules which ensure that MTAs that implement this proposal
> > do no harm to the handling of messages  for which they're not willing
> > to trust the sender's assertion of priority.  e.g. either they
> > trust the sender's assertion of priority or they simply ignore it.
>   
> I think this is a special case of your point 2.
> 
> > 2. a rule which asserts that when the claimed priority is accepted,
> > higher priority messages are treated no worse than lower priority
> > ones.  (as opposed to priority being interpreted however the MTA 
> > wants to)
> 
> OK - this sounds good, with the caveat that this is client
> specific. Priority of high from one MTA might be taken as higher than
> priority of HIGH from another MTA that is less trusted. A sentence
> like
> 
> "An MTA that accepts the priority property, will ensure that messages
> marked with higher priority received from the same MTA are treated
> with the same, or higher, priority for scheduling purposes"

no, I don't think this is a good idea.

in fact, I think the whole idea of having the queuing priority affected
by preceding MTAs is severely flawed.  for instance, the choke point 
might be closer to the receiver than the sender - and yet the sender 
might have privileges to set priority on the MTAs close to the receiver.  
why should the earlier MTAs dilute the sender's priority?

> I think you are mixing a couple of concepts here. I see priority as a
> dynamic quantity, therefore it is really only useful from one MTA to
> another. It should not be tied to the user, other than at submission time.

I think it's just the opposite.  Other than in a completely closed system,
there will inherently be some users who have permission to set message
priority and some who do not.  

> A user might start out requesting high priority, it hits the
> submission MTA(A). Based on local knowledge and rule processing, it
> asserts that in reality, this user is only allowed to request priority
> level 25 or below, so it downgrades it internally, sorts
> its queues appropriately. 

the problem is, MTA A doesn't know what permissions the user has with
MTA B, or with the MTAs nearer to the recipient.

> I dont see a chain of trust being useful either 

well, that's pretty much what you were describing.  but I've since
convinced myself that it's not the way to go.

> Message submitted to MTA(A) with priority HIGH,
> passed to MTA(B) which doesn't trust MTA(A). It ignores the parameter,
> and passes the message onwards to MTA(C) with no priority
> parameter. MTA(C) using local rules, determines that the recipient of
> the message has payed extra for priority processing, so assigns the
> message a given priority (say, 33). It can then pass this on to
> another MTA saying effectively I would like you to treat this message
> with priority 33, if you trust my judgement.

that's silly.  if MTA C can decide the message's priority in the absence
of any input from the sender, then we don't need the priority extension
at all.  if priority is to be very useful, it needs to be preserved 
end-to-end.  intermediate MTAs can ignore it, but they shouldn't try to
change it, because that's misrepresenting the sender's request.
that doesn't preclude an MTA giving better service to some recipients
over others, but recipient-derived priority should be independent from 
the sender-requested priority.

and if the purpose of priority is to make better use of limited resources 
then you want to be able to set it on a per-message basis, not have it
derived from the sender or recipient address and MTA-local rules.  

Keith

Date: Wed, 27 Jun 2001 07:52:53 -0400
To: Arnt Gulbrandsen <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: SMTP QoS
Cc: [email-masked]
Sender: [email-masked]

At 10:40 AM 6/26/2001, Arnt Gulbrandsen wrote:
>I venture to guess that people will drop max-priority mail because so much
>of it is spam, just like people now drop mail from <>.

The proposal for a priority bit is an attempt to provide a degree of 
quality of service.

We have a 30+ year history that an inadequately specified "priority" field 
will go unused.  Take a look at arpanet/internet level packet 
switching.  The last 6 years of work on IPv6 shows that trying to provide 
useful QoS is quite difficult.

As noted by others, without the rest of the total system specification, the 
priority field will be mis-used by a variety of senders.  This will 
guarantee that it be ignored by relays.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

From: "Koti" <[email-masked]>
To: <[email-masked]>
Subject: Need info about BASE64 encoding & BASE64 decoding
Date: Wed, 27 Jun 2001 16:46:54 +0530
Sender: [email-masked]

Hi,

Ref: RFC 2195, 2554.

In RFC 2554 ( SMTP), mentioned that, server challenge otherwise known as
ready response, is a 334 reply with the
text part containg a BASE64 encoded string, client answer consists of a line
containing BASE64 encoded string.

Is there any specific BASE64 algoritham ?
Where can i get more info about BASE64 algoritham?

Thanks,
- Koteswara Rao
Ph: 040 6513274 Extn: 8842
JUNO online services Dev Pvt Ltd.
GPR building, Begumpet,
Hyderabad, India
----------------------------------------------------------------
When one door of happiness closes, another opens; but often we look so long
at the closed door
that we do not see the one, which has opened for us. - Hellen Keller.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

To: Keith Moore <[email-masked]>
cc: John C Klensin <[email-masked]>, [email-masked]
Subject: Re: SMTP Service Extension for Priority
Date: Wed, 27 Jun 2001 09:27:43 BST
From: Julian Onions <[email-masked]>
Sender: [email-masked]

> 1. a set of rules which ensure that MTAs that implement this proposal
> do no harm to the handling of messages  for which they're not willing
> to trust the sender's assertion of priority.  e.g. either they
> trust the sender's assertion of priority or they simply ignore it.
  
I think this is a special case of your point 2.

> 2. a rule which asserts that when the claimed priority is accepted,
> higher priority messages are treated no worse than lower priority
> ones.  (as opposed to priority being interpreted however the MTA 
> wants to)

OK - this sounds good, with the caveat that this is client
specific. Priority of high from one MTA might be taken as higher than
priority of HIGH from another MTA that is less trusted. A sentence
like

"An MTA that accepts the priority property, will ensure that messages
marked with higher priority received from the same MTA are treated
with the same, or higher, priority for scheduling purposes"

This is regardless of whether it trusts the client or not. So from an
untrusted client, it might ignore the property, effectively saying all
messages are treated as normal priority. But with the effect that high
priority requests are treated no worse than low priority.

> 3. a story about authentication.  I can see two ways to do this:
> 
> - "chain of trust" model
>   sender authenticates to original MTA using SMTP AUTH, 
>   non-original MTAs can trust the priority of messages relayed from 
>   other MTAs if those MTAs also use SMTP AUTH.
>   this implies that MTAs don't relay priority unless they receive
>   the message from a trusted source.
> 
>   this is a weak model, as trust isn't really transitive.
>   but it could work in a limited scenario like a military organization.
> 
> - "capability model"
>   along with original message, client supplies (say in MAIL FROM)
>   a verifiable assertion of his ability to set priority this messages.
>   essentially this requires that the client sign the message
>   (modulo received headers) though you also could allow the originating 
>   MTA to sign the message based on the sender's SMTP AUTH credentials.
>   note that this isn't intended for authenticating the message to the recipie
nt;
>   the signature would not be passed to the recipient.
> 
>   this model would allow priorities to be relayed, but each MTA could
>   then decide (based on the signature) whether to accept the sender's
>   credentials. if the MTA did not accept them, it would ignore priority
>   (but it could still relay the priority and the signature to the next
>   MTA if it supported those extensions)

I think you are mixing a couple of concepts here. I see priority as a
dynamic quantity, therefore it is really only useful from one MTA to
another. It should not be tied to the user, other than at submission time.

A user might start out requesting high priority, it hits the
submission MTA(A). Based on local knowledge and rule processing, it
asserts that in reality, this user is only allowed to request priority
level 25 or below, so it downgrades it internally, sorts
its queues appropriately. 

It passes the message onto another MTA (B), and using the priority
parameter, asserts to this MTA "I would like you to consider this
message at a priority of 25". If this MTA(B) is willing to trust
MTA(A) for the purposes of priority, then it will take this on
board.

MTA(B) now determines the recipient is local, and is a distribution
list. It expands the list, and has a local policy that this list
members should be processed at low priority. So when the message is
passed on to MTA(C), it asserts "I would like you to treat this
message as low priority"

I dont see a chain of trust being useful either - it might happen, but
is not necesary. Message submitted to MTA(A) with priority HIGH,
passed to MTA(B) which doesn't trust MTA(A). It ignores the parameter,
and passes the message onwards to MTA(C) with no priority
parameter. MTA(C) using local rules, determines that the recipient of
the message has payed extra for priority processing, so assigns the
message a given priority (say, 33). It can then pass this on to
another MTA saying effectively I would like you to treat this message
with priority 33, if you trust my judgement.

Julian.

To: John C Klensin <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: SMTP Service Extension for Priority
Date: Wed, 27 Jun 2001 08:41:28 BST
From: Julian Onions <[email-masked]>
Sender: [email-masked]

> The discourse into other services Keith and I engaged in
> notwithstanding, I think that, if your draft is going to go
> anywhere, it will need at least two things that are not there at
> present:
> 
> (i) Either 
> 
>     --a requirement that the approach not be used with
>     authentication of the source and a description of the nature
>     of or conditions for that authentication (and, in Keith's
>     model, authorization to present a particular priority).  Or 
>     
>     --an analysis of why originator authentication is not needed.

OK - so would expanding the security section help? I don't want to be
prescriptive, as there are a lot of different cases that might make
sense. But a discussion on what an implementor might want to consider
for various possible cases could be included there. Is that the sort
of thing you are after? 
If so - I'll draft some text and send it out.

> (ii) An analysis of how this would interact with intermediate
> MTAs (e.g., the targets of lower-preference MX records that
> happened to be picked up as well as any submission MTA used by
> the initial (originating) MUA.  Or, again, an analysis of why
> that isn't a problem.    For example, you could try to insist
> that the option not be used where intermediate MTAs are present,
> but that involves other issues.  And, if you assume that
> intermediate MTAs might be present, note that their presence may
> have some implications for the trust relationships associated
> with originator authentication and authorization.

Ummm - I think you lost me here... I'm not sure what you are asking or
suggesting. The extension is meant to be used on a hop by hop basis,
and should be used regardless of what the hop type is. Is there some
similar extension that does this that I could refer to. In my mind,
this draft shares a lot of common ground with the SIZE extension.

Julian.

Date: Wed, 27 Jun 2001 00:17:19 -0500
To: "Koti" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: SMTP AUTH -  RFC2554
Cc: <[email-masked]>
Sender: [email-masked]

On 6/27/01 at 10:36 AM +0530, Koti wrote:

>1. what is server challenge in SMTP auth ?
>2. How client validate or decode this server chanllenge?
>3. what is client response?( Is ther any specific RFC or docs on "server
>challenge & client response" )
>4. How server validates client's response?

All of these depend on which SASL mechanism is being used. Each SASL 
mechanism has an RFC associated with it. See 
<http://www.iana.org/assignments/sasl-mechanisms> for a list of the 
registered SASL mechanisms and the RFCs which describes what the 
challenge and the response should be for each.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: "Koti" <[email-masked]>
To: <[email-masked]>
Subject: SMTP AUTH -  RFC2554
Date: Wed, 27 Jun 2001 10:36:12 +0530
Sender: [email-masked]

Ref: RFC 2554

Hi,

1. what is server challenge in SMTP auth ?
2. How client validate or decode this server chanllenge?
3. what is client response?( Is ther any specific RFC or docs on "server
challenge & client response" )
4. How server validates client's response?

Thanks,
- Koteswara Rao
Ph: 040 6513274 Extn: 8842
JUNO online services Dev Pvt Ltd.
GPR building, Begumpet,
Hyderabad, India
----------------------------------------------------------------
When one door of happiness closes, another opens; but often we look so long
at the closed door
that we do not see the one, which has opened for us. - Hellen Keller.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

From: Keith Moore <[email-masked]>
To: John C Klensin <[email-masked]>
cc: Julian Onions <[email-masked]>, Keith Moore <[email-masked]>, [email-masked]
Subject: Re: SMTP Service Extension for Priority 
Date: Tue, 26 Jun 2001 13:21:00 -0400
Sender: [email-masked]

my assessment is that this proposal needs two or three things to 
become viable:

1. a set of rules which ensure that MTAs that implement this proposal
do no harm to the handling of messages  for which they're not willing
to trust the sender's assertion of priority.  e.g. either they
trust the sender's assertion of priority or they simply ignore it.

2. a rule which asserts that when the claimed priority is accepted,
higher priority messages are treated no worse than lower priority
ones.  (as opposed to priority being interpreted however the MTA 
wants to)

3. a story about authentication.  I can see two ways to do this:

- "chain of trust" model
  sender authenticates to original MTA using SMTP AUTH, 
  non-original MTAs can trust the priority of messages relayed from 
  other MTAs if those MTAs also use SMTP AUTH.
  this implies that MTAs don't relay priority unless they receive
  the message from a trusted source.

  this is a weak model, as trust isn't really transitive.
  but it could work in a limited scenario like a military organization.

- "capability model"
  along with original message, client supplies (say in MAIL FROM)
  a verifiable assertion of his ability to set priority this messages.
  essentially this requires that the client sign the message
  (modulo received headers) though you also could allow the originating 
  MTA to sign the message based on the sender's SMTP AUTH credentials.
  note that this isn't intended for authenticating the message to the recipient;
  the signature would not be passed to the recipient.

  this model would allow priorities to be relayed, but each MTA could
  then decide (based on the signature) whether to accept the sender's
  credentials. if the MTA did not accept them, it would ignore priority
  (but it could still relay the priority and the signature to the next
  MTA if it supported those extensions)

   

Date: Tue, 26 Jun 2001 13:03:53 -0400
From: John C Klensin <[email-masked]>
Subject: Re: SMTP Service Extension for Priority
To: Julian Onions <[email-masked]>
Cc: Keith Moore <[email-masked]>, [email-masked]
Sender: [email-masked]

Julian,

The discourse into other services Keith and I engaged in
notwithstanding, I think that, if your draft is going to go
anywhere, it will need at least two things that are not there at
present:

(i) Either 

    --a requirement that the approach not be used with
    authentication of the source and a description of the nature
    of or conditions for that authentication (and, in Keith's
    model, authorization to present a particular priority).  Or 
    
    --an analysis of why originator authentication is not needed.

(ii) An analysis of how this would interact with intermediate
MTAs (e.g., the targets of lower-preference MX records that
happened to be picked up as well as any submission MTA used by
the initial (originating) MUA.  Or, again, an analysis of why
that isn't a problem.    For example, you could try to insist
that the option not be used where intermediate MTAs are present,
but that involves other issues.  And, if you assume that
intermediate MTAs might be present, note that their presence may
have some implications for the trust relationships associated
with originator authentication and authorization.

      john

--On Tuesday, June 26, 2001 2:12 PM +0100 Julian Onions
<[email-masked]> wrote:

> I don't think the current draft is all that is required to
> implement all services that you might be interested in. What I
> think we have though is a new tool. There is no method for
> indicating priority in the smtp envelope, or a means of
> adjusting it (other that rewriting header fields - yuck). 
> 
> So this mechanism gives the transfer capability. 
> 
> Given that, you can build on it. For instance the military
> STANAG 4406/ACP-123 precedence fields should be mapped to a
> priority value, but we didn't think that was appropriate for
> this draft. It can be specified in another document how those
> values should be mapped to the SMTP extension, and they can
> those mappings can then be controlled by the bodies intersted
> in those mappings.
> 
> Whilst a message might start out as high priority, it may get
> downgraded on its path (list expansion being one case) or
> upgraded maybe (reaching its latest delivery time). I'd rather
> not specify those mechanisms here, they can be built up in
> other documents.
> 
> Similarly, you might well come up with authenticated senarios
> for real life deployment at ISPs or major switching hubs, they
> can also use this basic mechanism.
> 
> If we have the tool available, we can build solutions around
> it, hence  the draft tries to stay as simple and focused as
> possible.
> 
> For us it gives us the tools to solve some military senarios
> whilst being generic enough to provide other solutions (or at
> least thats the goal).
> 
> Julian.

Date: Tue, 26 Jun 2001 07:35:56 -0700 (PDT)
From: [email-masked]
Subject: Re: Need clarification in SMTP RFC 2554
To: Koti <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> Hi,

> In RFC 2554 - SMTP service extension for authentication, in AUTH command
> mentioned that "the client should send EHELO command after successful SASL
> negotioation which results in the negotiation of a security layer."

> Questions:
> 1. client should give EHLO if it wants extended SMTP service then server
>     gives"250 - ..." as a reply after that client will give one auth
>     mechanisam a and conversatioin goes depending on authentication method.
>     why client needs to give EHLO as first command after SASL negotiation?

Two reasons:

(1) Because the available options may have changed as a result of entering
    an authenticated state. A server may restrict access to some facilities
    to users that have authenticated, and implement this by only displaying
    the options when they are available.

(2) Because SASL negotiation can result in an integrity layer being
    introduced. If someone is tampering with the connection they could have
    removed something from the list prior to integrity checking but cannot
    do so after it is in place, so getting the list of options again avoids
    certain kinds of attacks.

> 2. If it supposed to give EHLO after successful SASL negotiation,
>    How server differentiate whether that command is before SASL negotiatioin
>    or after negotiation?

Because the server retains state and knows whether SASL negotiation has
occurred and whether or not it has been successful.

> 3. In authentication protocol exchange server chalenge, known as ready
>    response is a 334 reply with the text part containing Base64 encoded
>    string, Client answer consitsts Base64 encoded string.
>    what this string?

The response to the challenge.

>     How client validate that string?

How the string is validated is specific to the SASL mechanism being used
and to the implementation of that mechanism.

> 4. when exactly CRAM or some other auth mechanisam should start?

I believe CRAM starts with the client AUTH command, which includes the
client nonce.

				Ned

Date: Tue, 26 Jun 2001 16:40:31 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: SMTP Service Extension for Priority
Sender: [email-masked]

I venture to guess that people will drop max-priority mail because so much
of it is spam, just like people now drop mail from <>.

--Arnt

To: Jacob Palme <[email-masked]>
Cc: [email-masked]
Subject: Re: SMTP Service Extension for Priority 
From: [email-masked]
Date: Tue, 26 Jun 2001 10:22:15 -0400
Sender: [email-masked]

--==_Exmh_-382494783P
Content-Type: text/plain; charset=us-ascii

On Tue, 26 Jun 2001 14:13:50 +0200, Jacob Palme <[email-masked]>  said:
> Is "Delivery-By" a commonly used header, or just something
> you suggested? I am sure the fundamentalists will say that
> this should be on the envelope and not in the heading!

RFC2852:  Deliver By SMTP Service Extension. D. Newman. June 2000. (Format:
     TXT=29285 bytes) (Updates RFC1894) (Status: PROPOSED STANDARD)

It's the ESMTP 'DELIVERBY' keyword, so it IS in the envelope.

/Valdis

--==_Exmh_-382494783P
Content-Type: application/pgp-signature

--==_Exmh_-382494783P--

From: Keith Moore <[email-masked]>
To: Julian Onions <[email-masked]>
cc: Keith Moore <[email-masked]>, John C Klensin <[email-masked]>, [email-masked]
Subject: Re: SMTP Service Extension for Priority 
Date: Tue, 26 Jun 2001 10:21:12 -0400
Sender: [email-masked]

I think it's a bit more complex than your scenarios, given that

- without authentication, there's no reason not to ask for the 
  highest priority
- consequently there will be some incentive to bias an MTA against
  high priority messages, or to ignore priority
- if you do have authentication, the effects of priority are likely
  to change from one sender to another.

thus asserting priority can easily give you better treatment 
with one MTA (the one which recognizes your authentication credentials)
and worse with the next (which doesn't).

it might not prevent delivery of your message, but it might increase
the variability/predictability with which messages are handled.

To: Graham Klyne <[email-masked]>
Cc: Dave Crocker <[email-masked]>, Julian Onions <[email-masked]>, [email-masked]
Subject: Re: SMTP Service Extension for Priority 
From: [email-masked]
Date: Tue, 26 Jun 2001 10:15:20 -0400
Sender: [email-masked]

--==_Exmh_-397122448P
Content-Type: text/plain; charset=us-ascii

On Mon, 25 Jun 2001 20:53:07 BST, Graham Klyne said:
> As it happens, I think the priority proposal would have a significant use 
> in connection with the timely delivery proposal, namely to expedite 
> delivery of a status response.

Hmm.  If I send a "Lunch?" email, it needs to get there by 12:30PM or
some similar time.  I haven't convinced myself whether the DSN/MDN with the
status response should go back with a high-priority or a delivery-by.
A case can be made for either one - high-priority is suitable in some
cases, when we need a timely notification that it was/wasn't delivered
so (perhaps) alternate plans or a backup scheme can be used (if the mail
wasn't delivered to his pager by 11:45AM, we need to call his office now).

In other cases, if the status response is itself delayed past time X,
it too is useless and can be dropped (presumably because some out-of-band
event will convey the information - if Bill doesn't *reply* about lunch
before 12:30, we'll know not to expect him, so a status response can be
dropped on the floor too).

And of course, in some cases a low/normal priority on the status reply
is acceptable.....

/Valdis (who should take time out today to actually read the draft ;)

--==_Exmh_-397122448P
Content-Type: application/pgp-signature

--==_Exmh_-397122448P--

To: Keith Moore <[email-masked]>
cc: John C Klensin <[email-masked]>, [email-masked]
Subject: Re: SMTP Service Extension for Priority
Date: Tue, 26 Jun 2001 15:12:42 BST
From: Julian Onions <[email-masked]>
Sender: [email-masked]

> In my view, while it might be useful in a controlled environment,
> creating this 'tool' without defining how it is used is likely to 
> decrease interoperability between MTAs, and thus, decrease the
> reliability of Internet mail.  

well there are certainly some inventive people out there, but I don't
see how it will decrease reliability.

Senario 1: client request priority of 99, server replies 5XX. Message
	is bounced. 
Senario 2: client request priority of 99, server silently downgrades
	to normal.
Senario 3: client request priority of 99, server replies 4XX. Message
	queued for retry.

Results:
Senario 1: message is not lost, but is returned to sender, possibly with
an appropriate message. OK, an ISP or hub might field an MTA which rejects
all messages with priority > 1, so building a road block, but they could make
a much better road block responding to the MAIL FROM field!

Senario 2: message delivered as normal.

Senario 3: this is the only potential problem case. If the client
continues to retry for ever, and the server always replies 4XX, then
it will get stuck. However this can already happen with MAIL FROM or
any of the other verbs. Intelligent clients time out the message.

Furthermore,  you can simulate the behaviour right now by scanning for the 
priority: field, its just more intensive, less reliable, doesn't work
per recipient and does not support the possible dynamic nature of
priority. 

Like the SIZE extension, it has drawbacks if you wait until
you have the whole message before you make a decision.

Julian.

Date: 	Tue, 26 Jun 2001 17:11:51 +0300
From: Matti Aarnio <[email-masked]>
To: Koti <[email-masked]>
Cc: [email-masked]
Subject: Re: Need clarification in SMTP RFC 2554
Sender: [email-masked]

On Tue, Jun 26, 2001 at 07:05:40PM +0530, Koti wrote:
> Content-Type: multipart/alternative;
> 	boundary="----=_NextPart_000_041B_01C0FE72.FDDDEB00"

  NEVER post  text/html  -- any email with HTML in it goes into
junk folder for processing if I have no better things to do...
( I use  "TEXT/HTML"  is signature characteristics of SPAM! )

> Hi,
> 
> In RFC 2554 - SMTP service extension for authentication, in AUTH command 
> mentioned that "the client should send EHELO command after successful SASL 
> negotioation which results in the negotiation of a security layer."
> 
> Questions:
> 1. client should give EHLO if it wants extended SMTP service then server
>     gives"250 - ..." as a reply after that client will give one auth
>     mechanisam and conversatioin goes depending on authentication method.
>     why client needs to give EHLO as first command after SASL negotiation?

   Just like with  STARTTLS,  after successfull authentication the server
   may enable extensions which are not normally available for everybody.
   Also, some extentions may get disabled when authentication is done.

> 2. If it supposed to give EHLO after successful SASL negotiation,
>     How server differentiate whether that command is before SASL negotiatioin 
>     or after negotiation?

   The server can keep state internally -- indeed it MUST keep state
   for several basic SMTP protocol details, adding this is trivial.

> 3. In authentication protocol exchange server chalenge, known as ready
>   response is a 334 reply with the text part containing Base64 encoded string,
>     Client answer consitsts Base64 encoded string.
>     what this string?
>     How client validate that string?

  That depends on the details of the particular authentication
  mechanism.

> 4. when exactly CRAM or some other auth mechanisam should start?

  a) make (TCP) connection
  b) see 220 greeting
  c) do first EHLO greeting
  d) see capabilities reports (including AUTH)
  d2) Do STARTTLS, if capabilities show it, and do its EHLO greeting
      (continuing presuming the AUTH capability exists..)
  e) do AUTH
  f) do EHLO greeting again to see then current capabilities
  g) continue with message transmission

> Thanks in advanse,
> - Koteswara Rao
> Ph: 040 6513274 Extn: 8842
> JUNO online services Dev Pvt Ltd.
> GPR building, Begumpet,
> Hyderabad, India

-- 
/Matti Aarnio	<[email-masked]>

Date: Tue, 26 Jun 2001 07:01:07 -0700 (PDT)
From: [email-masked]
Subject: Re: SMTP Service Extension for Priority
To: Jacob Palme <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > I may use Delivery-By: if it's time-critical ("Hey George,
> > lunch at Blue River
> > Cafe at 12:30?") and can be discarded if the time constraint
> > isn't met. In this case, I don't care about order, I just care if *THIS*
> > mail gets there by a specific time or not.

> Is "Delivery-By" a commonly used header, or just something
> you suggested? I am sure the fundamentalists will say that
> this should be on the envelope and not in the heading!

Deliver-by isn't a header, it is an SMTP extension. See RFC 2852.

				Ned

From: Keith Moore <[email-masked]>
To: Julian Onions <[email-masked]>
cc: John C Klensin <[email-masked]>, Keith Moore <[email-masked]>, [email-masked]
Subject: Re: SMTP Service Extension for Priority 
Date: Tue, 26 Jun 2001 09:43:50 -0400
Sender: [email-masked]

In my view, while it might be useful in a controlled environment,
creating this 'tool' without defining how it is used is likely to 
decrease interoperability between MTAs, and thus, decrease the
reliability of Internet mail.  

Keith

From: "Koti" <[email-masked]>
To: <[email-masked]>
Subject: Need clarification in SMTP RFC 2554
Date: Tue, 26 Jun 2001 19:05:40 +0530
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_041B_01C0FE72.FDDDEB00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

In RFC 2554 - SMTP service extension for authentication, in AUTH command =

mentioned that "the client should send EHELO command after successful =
SASL=20
negotioation which results in the negotiation of a security layer."

Questions:
1. client should give EHLO if it wants extended SMTP service then server
    gives"250 - ..." as a reply after that client will give one auth =
mechanisam a
    and conversatioin goes depending on authentication method.
    why client needs to give EHLO as first command after SASL =
negotiation?

2. If it supposed to give EHLO after successful SASL negotiation,
    How server differentiate whether that command is before SASL =
negotiatioin=20
    or after negotiation?

3. In authentication protocol exchange server chalenge, known as ready =
response
    is a 334 reply with the text part containing Base64 encoded string,
    Client answer consitsts Base64 encoded string.
    what this string?
    How client validate that string?

4. when exactly CRAM or some other auth mechanisam should start?

Thanks in advanse,
- Koteswara Rao
Ph: 040 6513274 Extn: 8842
JUNO online services Dev Pvt Ltd.
GPR building, Begumpet,
Hyderabad, India
----------------------------------------------------------------
When one door of happiness closes, another opens; but often we look so =
long at the closed door=20
that we do not see the one, which has opened for us. - Hellen Keller.

------=_NextPart_000_041B_01C0FE72.FDDDEB00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>In RFC 2554 - SMTP service extension for authentication, in AUTH =
command=20
</DIV>
<DIV>mentioned that "the client should send EHELO command after =
successful SASL=20
</DIV>
<DIV>negotioation which results in the negotiation of a security =
layer."</DIV>
<DIV>&nbsp;</DIV>
<DIV>Questions:</DIV>
<DIV>1. client&nbsp;should give EHLO if it wants extended SMTP service =
then=20
server</DIV>
<DIV>&nbsp;&nbsp;&nbsp; gives"250 - ..." as a reply after that client =
will give=20
one auth mechanisam a</DIV>
<DIV>&nbsp;&nbsp;&nbsp; and conversatioin goes depending on =
authentication=20
method.</DIV>
<DIV>&nbsp;&nbsp;&nbsp; why client needs to give EHLO as first command =
after=20
SASL negotiation?</DIV>
<DIV>&nbsp;</DIV>
<DIV>2. If it supposed to give EHLO after successful SASL =
negotiation,</DIV>
<DIV>&nbsp;&nbsp;&nbsp; How server differentiate whether that command is =
before=20
SASL negotiatioin </DIV>
<DIV>&nbsp;&nbsp;&nbsp; or after negotiation?</DIV>
<DIV>&nbsp;</DIV>
<DIV>3. In authentication protocol exchange server chalenge, known as =
ready=20
response</DIV>
<DIV>&nbsp;&nbsp;&nbsp; is a 334 reply with the text part containing =
Base64=20
encoded string,</DIV>
<DIV>&nbsp;&nbsp;&nbsp; Client answer consitsts Base64 encoded =
string.</DIV>
<DIV>&nbsp;&nbsp;&nbsp; what this string?</DIV>
<DIV>&nbsp;&nbsp;&nbsp; How client validate&nbsp;that string?</DIV>
<DIV>&nbsp;</DIV>
<DIV>4. when exactly CRAM or some other auth mechanisam should =
start?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks in advanse,<BR>- Koteswara Rao<BR>Ph: 040 6513274 Extn: =
8842<BR>JUNO=20
online services Dev Pvt Ltd.<BR>GPR building, Begumpet,<BR>Hyderabad,=20
India<BR>----------------------------------------------------------------=
<BR>When=20
one door of happiness closes, another opens; but often we look so long =
at the=20
closed door <BR>that we do not see the one, which has opened for us. - =
Hellen=20
Keller.<BR></DIV></BODY></HTML>

------=_NextPart_000_041B_01C0FE72.FDDDEB00--

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Date: Tue, 26 Jun 2001 14:13:50 +0200
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Re: SMTP Service Extension for Priority
Sender: [email-masked]

At 14.14 -0400 01-06-25, [email-masked] wrote:
>I may use Delivery-By: if it's time-critical ("Hey George, 
>lunch at Blue River
>Cafe at 12:30?") and can be discarded if the time constraint 
>isn't met. In
>this case, I don't care about order, I just care if *THIS* 
>mail gets there
>by a specific time or not.

Is "Delivery-By" a commonly used header, or just something
you suggested? I am sure the fundamentalists will say that
this should be on the envelope and not in the heading!
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

To: John C Klensin <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: SMTP Service Extension for Priority
Date: Tue, 26 Jun 2001 14:12:11 BST
From: Julian Onions <[email-masked]>
Sender: [email-masked]

I don't think the current draft is all that is required to implement
all services that you might be interested in. What I think we have
though is a new tool. There is no method for indicating priority in the
smtp envelope, or a means of adjusting it (other that rewriting header
fields - yuck). 

So this mechanism gives the transfer capability. 

Given that, you can build on it. For instance the military STANAG
4406/ACP-123 precedence fields should be mapped to a priority value,
but we didn't think that was appropriate for this draft. It can be
specified in another document how those values should be mapped to the
SMTP extension, and they can those mappings can then be controlled by the
bodies intersted in those mappings.

Whilst a message might start out as high priority, it may get
downgraded on its path (list expansion being one case) or upgraded
maybe (reaching its latest delivery time). I'd rather not specify those
mechanisms here, they can be built up in other documents.

Similarly, you might well come up with authenticated senarios for real
life deployment at ISPs or major switching hubs, they can also use this
basic mechanism.

If we have the tool available, we can build solutions around it, hence 
the draft tries to stay as simple and focused as possible.

For us it gives us the tools to solve some military senarios whilst being
generic enough to provide other solutions (or at least thats the goal).

Julian.

From: Keith Moore <[email-masked]>
To: Julian Onions <[email-masked]>
cc: [email-masked]
Subject: Re: SMTP Service Extension for Priority 
Date: Tue, 26 Jun 2001 09:02:51 -0400
Sender: [email-masked]

I guess I can see how this would be useful in a military environment,
where the organization can define policy for its entire mail network,
and persumably can control access to its entire network (so authentication
is less of an issue).

It's much more difficult to see how this can be usable on an Internet-scale.

Keith

Date: Tue, 26 Jun 2001 08:52:48 -0400
From: John C Klensin <[email-masked]>
Subject: Re: SMTP Service Extension for Priority
To: Keith Moore <[email-masked]>
Cc: Julian Onions <[email-masked]>, [email-masked]
Sender: [email-masked]

--On Tuesday, 26 June, 2001 08:44 -0400 Keith Moore
<[email-masked]> wrote:

>> It seems to me that there are two important cases here:
>> 
>> * The MTAs of concern are under the control of either the
>> sender or the receiver.  In this case, the "guessing game" is
>> no worse than the one that is played with every message: you
>> need to guess what "from:" and "subject" lines, and envelope
>> address to use to maximize the chance that I will read your
>> mail or, put differently, which ones to avoid to minimize the
>> chance that I will delete it without reading (or have agents
>> or filters do that for me).
> 
> I guess I disagree - first of all, we don't usually expect to
> guess "From".

But people who discover that they are being filtered on
particular From: patterns do just that.

>  We do have to choose a subject, but that choice
> is informed by our vast experience in communicating between 
> human beings  with words.  Priority is less obvious, and it
> adds another dimension.  And if we're just making a facility
> for filtering by the sender or receiver, an Importance header
> works just as well (are we really going to set this separately
> on a per-recipient basis?)

Whether a header is appropriate depends on whether you expect
the filtering/ classification to be done by the delivery MTA (or
a trusted/designated intermediate one) or the MUA and about how
you feel about layering violations.   One probably would not set
it on a per-recipient basis (although I can see setting
different priorities for each of the To, CC, and Bcc
recipients).  But, as a recipient, I'd certainly like to be able
to adjust incoming priorities differentially from different (and
frequent) senders.

>> * The MTAs making the decision are "in the middle", and not
>> under the control of either sender or recipient, or anyone
>> both accept as an appropriate intervening authority.   That
>> scenario is basically equivalent to all of the other
>> interception objects on the network (what you think about
>> those is well-established; let's not have the discussion here
>> again), but with one major difference -- there will be no
>> intermediate MTAs doing stupid things out of ignorance of the
>> protocol, since a priority parameter cannot be sent to any
>> MTA that does not advertise it. That is a small advantage for
>> this case, although perhaps a trivially small one.
> 
> I guess I don't consider things to be interception objects
> unless they actually intercept traffic, and an MTA doesn't
> qualify.
> 
> My question is - why is it useful for Internet mail users to 
> allow/encourage intermediate MTAs to do arbitrary filtering 
> based on an unauthenticated priority?

Strawman.  I've already agreed that the facility is dubious
without authentication and at least suggested that I'd want any
filtering intermediates to do so with explicit authorization
from the recipient, which ought to be sufficient to eliminate
"arbitrary" as a case.

> In other words - I do think a priority facility could be
> useful, but I think we're missing some significant pieces from
> the current design that would be required to make it useful.

Absolutely.  I think I said that in my initial note.  And, while
I think I've got some ideas about what is needed, it is clear to
me that this draft, in its current form, isn't it.

> And I'm not quite sure what pieces are missing, or whether
> it's feasible to supply them.

     john

From: Keith Moore <[email-masked]>
To: John C Klensin <[email-masked]>
cc: Keith Moore <[email-masked]>, Julian Onions <[email-masked]>, [email-masked]
Subject: Re: SMTP Service Extension for Priority 
Date: Tue, 26 Jun 2001 08:44:21 -0400
Sender: [email-masked]

> It seems to me that there are two important cases here:
> 
> * The MTAs of concern are under the control of either the sender
> or the receiver.  In this case, the "guessing game" is no worse
> than the one that is played with every message: you need to
> guess what "from:" and "subject" lines, and envelope address to
> use to maximize the chance that I will read your mail or, put
> differently, which ones to avoid to minimize the chance that I
> will delete it without reading (or have agents or filters do
> that for me).

I guess I disagree - first of all, we don't usually expect to
guess "From".  We do have to choose a subject, but that choice
is informed by our vast experience in communicating between 
human beings  with words.  Priority is less obvious, and it
adds another dimension.  And if we're just making a facility
for filtering by the sender or receiver, an Importance header
works just as well (are we really going to set this separately
on a per-recipient basis?)

> * The MTAs making the decision are "in the middle", and not
> under the control of either sender or recipient, or anyone both
> accept as an appropriate intervening authority.   That scenario
> is basically equivalent to all of the other interception objects
> on the network (what you think about those is well-established;
> let's not have the discussion here again), but with one major
> difference -- there will be no intermediate MTAs doing stupid
> things out of ignorance of the protocol, since a priority
> parameter cannot be sent to any MTA that does not advertise it.
> That is a small advantage for this case, although perhaps a
> trivially small one.

I guess I don't consider things to be interception objects unless
they actually intercept traffic, and an MTA doesn't qualify.

My question is - why is it useful for Internet mail users to 
allow/encourage intermediate MTAs to do arbitrary filtering 
based on an unauthenticated priority?

In other words - I do think a priority facility could be useful,
but I think we're missing some significant pieces from the current
design that would be required to make it useful. And I'm not
quite sure what pieces are missing, or whether it's feasible
to supply them.

Keith

Date: Tue, 26 Jun 2001 07:48:03 -0400
From: John C Klensin <[email-masked]>
Subject: Re: CRAM - MD5
To: Koti <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

--On Tuesday, 26 June, 2001 13:04 +0530 Koti
<[email-masked]> wrote:

> Hi,
> 
> For example: I am using Eudora as an email client & gave pop
> server name for getting mails, smtp server name for sending
> mails. For example pop server
> is pop3.mail.yahoo.com, smtp.mail.yahoo.com. If set an option
> like "use authentication mechanisam while logging." assume
> that client(eudora) & server (smtp.yahoo)
> supports that authentication mechanisam.

It appears that some tutorial is needed, and that you are not
the only one confused.  Let me try...

First of all, I have no idea whether Yahoo (or whatever server
you are using) supports CRAM-MD5.  There are several possible
"authentication mechanisms"; you would need to clarify whether
what they support is usuable by your client.

As Paul Smith's note more or less suggests, the term "shared
secret" is a generalization. I.e., "passwords" are a special
case of shared secrets.  For technical and security reasons
(consult any good reference on hash-based authentication or
signature systems if you are interested), it is desirable that
the "secrets" used in CRAM-MD5 and methods similar to it be much
longer than the traditional typical "password" (it is also
desirable that passwords be longer and more complex than the
typical password, which is not an independent observation).

The answer to how you and the server get and retain the shared
secret is the same as it would be with passwords -- you need to
set the value for the server in a secure way, or transmit it out
of band.  And then you need to supply it, or a key to unlock a
saved copy of it, from the client to the server at appropriate
times.  Storing it locally in cleartext is not generally
considered to be a good practice.

More generally, if one does authentication by transmitting a
password (or "shared secret") across the network in cleartext,
one is vunerable to the possibility of someone compromising and
monitoring the network and thereby obtaining the secret, which
can later by used to compromise your account.   In order to
reduce that risk at least one of the three conditions implied by
that statement must be changed, i.e.:

	(i) One avoids tranmitting the secret at all.  This
	turns into an exercise of proving to the server that you
	know a particular secret without disclosing the secret
	or passing it across the network.  CRAM-MD5 is a member
	of this class of techniques.
	
	(ii) One encrypts the transmission of the secret, either
	directly  or by encrypting the entire data stream in
	which the secret (or password) is embedded.  The
	approaches based on using SSL or TLS to hide
	authentication transactions fall into this class.
	
	(iii) One eliminates the use of a shared secret at all,
	relying instead on, e.g., a public key approach.

There are no perfect solutions; each of the above has its
advantages and disadvantages.  And, in all cases, any method not
supported by both your client software and the server software
is not going to be available to you.

So...

> 1. then How can server & client maintain shared secret?

More or less the same way they do passwords.  From the client
side, ideally the way you ideally maintain passwords, i.e., by
not writing them down or keeping them on your computer.  On the
server side, there is an additional complication, which is that
traditional passwords can be stored in a one-way encrypted
(hashed) form, while techniques similar to CRAM-MD5 require that
the server be able to recover the secret (or an algorithmic
variant on it) in order to make the required calculations.  How
much additional protection (or risk) this difference implies is
debated, but it essentially trades off reduced risk from
interception of the password on the network for increased risk
of passwords (secrets) being compromised if the server is
compromised.

> 2. Is it some constat string understood by client & server ?

typically

> 3. if somebody implements new email client which supports those
>     auth mechanisams, How it will know the shared secret? how
> it will connect to that server?

In the same fashion that a client and server are instructed
about a password.   I.e., either the secret is generated by, and
stored on, the server or as a part of its operational setup and
then transmitted, preferably in some secure way, to the user; or
the user picks and specifies the secret and transmits it to the
server (again, preferably in some secure way).

Hope that helps.
    john

Date: Mon, 25 Jun 2001 20:53:07 +0100
To: [email-masked]
From: Graham Klyne <[email-masked]>
Subject: Re: SMTP Service Extension for Priority 
Cc: Dave Crocker <[email-masked]>, Julian Onions <[email-masked]>, [email-masked]
Sender: [email-masked]

At 02:14 PM 6/25/01 -0400, [email-masked] wrote:
>On Sun, 24 Jun 2001 13:59:27 EDT, Dave Crocker said:
> > This proposal appears to be directly competitive with Deliver-By (and, by
> > derivation, the Timely Confirmation proposal.)
>
>It's not *directly* competitive.
>
>I may use Delivery-By: if it's time-critical ("Hey George, lunch at Blue River
>Cafe at 12:30?") and can be discarded if the time constraint isn't met. In
>this case, I don't care about order, I just care if *THIS* mail gets there
>by a specific time or not.
>
>Priority sorting is a different issue.

[...]

In what you say, and in what the main part of the referenced draft 
describes, I generally agree.  But I notice that the draft also makes a 
(spurious?) reference to:

    o    Meeting certain service level agreements.

which, I think, falls more into the territory addressed by the timely 
delivery proposal, whose primary focus is achieving, as nearly as possible, 
some kind of deterministic performance from the senders PoV (which is, I 
think, a kind of meeting a service level agreement).

As it happens, I think the priority proposal would have a significant use 
in connection with the timely delivery proposal, namely to expedite 
delivery of a status response.

#g

Date: Tue, 26 Jun 2001 10:12:06 +0100
To: "Koti" <[email-masked]>, "John C Klensin" <[email-masked]>
From: Paul Smith <[email-masked]>
Subject: Re: CRAM - MD5
Cc: <[email-masked]>
Sender: [email-masked]

>For example: I am using Eudora as an email client & gave pop server name
>for getting mails, smtp server name for sending mails. For example pop
>server
>is pop3.mail.yahoo.com, smtp.mail.yahoo.com. If set an option like "use
>authentication mechanisam while logging." assume that client(eudora) &
>server (smtp.yahoo)
>supports that authentication mechanisam.
>1. then How can server & client maintain shared secret?
>2. Is it some constat string understood by client & server ?
>3. if somebody implements new email client which supports those
>     auth mechanisams, How it will know the shared secret? how it will
>connect to that server?

I always thought that the 'shared secret' was essentially another term for 
'password' (there's no reference to a 'password' in the CRAM-MD5 standards 
as far as I can see).

If I'm wrong I'm sure someone will tell me.... ;-)

Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

To: [email-masked]
Subject: Re: SMTP Service Extension for Priority
Date: Tue, 26 Jun 2001 09:39:01 BST
From: Julian Onions <[email-masked]>
Sender: [email-masked]

Well first - thanks for all the comments!

If I can take a few of them in turn, and perhaps explain the
background a little. 

We do a lot of work with military systems, and they make use of
priority a great deal. They have different grades of messages from
routine traffic all the way up to FLASH priority ("ATTACK NOW!"). They
also have grades of service based on the precedence (like 3 minutes max
for delivery of a flash message). Under certain conditions they invoke
MINIMIZE conditions whereby only important traffic is allowed through
(to relieve congestion etc), so all traffic below a certain priority
will be ignored/saved/left unprocessed until the restriction is
lifted. Finally, different priorities (military call them precedences)
can be assigned to a messages To and CC recipients (maybe High
priority for To, and low for CC for instance).

Anyway - with that background, this extension allows the chance to
pass on the priority at a place in the protocol sufficient to make
full use of it. 

To respond to the comments...

AUTH may well be required to act on the priority - but that is really
down to the local setup. I don't think its something that should be
dictated.  If I wish to honor the protocol at this MTA for all, then
that is allowed (though maybe unwise). Likewise, if I wish to ignore
the priority from all connections except one, that is also allowed by
the draft. Section 7 does hint that you may need to do some of this.
In certain closed environments you may trust all connections and act
on the priority passed. Out on the wild internet, you will probably
only act on it from a few trusted connections (though see closing
comments).

If a client asserts a priority that the MTA dislikes, then it may take
several actions, including ignoring the request, or bouncing the
message, or just reverting to what it would do if no request was
present. 

When a message is relayed, it is down to the MTA what it may pass
on. It may just pass on the incoming priority, it may pass on its own
notion of priority or may not pass on anything. Obviously in a
cooperative environment, it would use and pass on the incoming
priority, subject to any AUTH checks.

As others have said, priority and importance are somewhat linked, but
not completely. You can come up with (somewhat contrived) examples of
high priority, low importance; and low priority, high importance
messages. 

So really the draft is aimed at MTA to MTA traffic. The receiving UA
would be unaware of the priority that it was transfered with, though
might be able to deduce from other fields what it might have been.

In the military environment, this maps extremely well to service
extensions in use there. In the commercial environment, I can see it
being used in a variety of ways, mostly in localised enclaves though,
such as ISP routing their customer traffic ahead of other traffic
maybe, or providing grades of service for a fee. 

Use in the wild untamed internet I suspect will be more minimal,
although I could see low priority traffic being acted on. e.g., any
priority request above normal, we'll ignore, but we will respond to
requests for low priority processing - thus allowing bulk mail/dist
list processing to be passed on in a well defined way.

Julian.

From: "Koti" <[email-masked]>
To: "John C Klensin" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: CRAM - MD5
Date: Tue, 26 Jun 2001 13:04:59 +0530
Sender: [email-masked]

Hi,

For example: I am using Eudora as an email client & gave pop server name
for getting mails, smtp server name for sending mails. For example pop
server
is pop3.mail.yahoo.com, smtp.mail.yahoo.com. If set an option like "use
authentication mechanisam while logging." assume that client(eudora) &
server (smtp.yahoo)
supports that authentication mechanisam.
1. then How can server & client maintain shared secret?
2. Is it some constat string understood by client & server ?
3. if somebody implements new email client which supports those
    auth mechanisams, How it will know the shared secret? how it will
connect to that server?

thanks,
- Koti
Off: 040 6513274 Extn: 8842
----------------------------------------------------------------
When one door of happiness closes, another opens; but often we look so long
at the closed door
that we do not see the one, which has opened for us. - Hellen Keller.

----- Original Message -----
From: "John C Klensin" <[email-masked]>
To: "Koti" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, June 25, 2001 10:26 PM
Subject: Re: CRAM - MD5

>
>
>
> --On Monday, 25 June, 2001 18:22 +0530 Koti
> <[email-masked]> wrote:
>
> > Ref: CRAM-MD5, challenge reply authentication mechanisam RFC
> > 2195.
> >
> > Hi,
> >
> > 1. How client & server maintain shared secret?
>
> Any way they like.  This is deliberately not specified in the
> standard.
>
>    john

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Date: Tue, 26 Jun 2001 01:43:28 -0400
From: John C Klensin <[email-masked]>
Subject: Re: SMTP Service Extension for Priority
To: Keith Moore <[email-masked]>
Cc: Julian Onions <[email-masked]>, [email-masked]
Sender: [email-masked]

--On Monday, 25 June, 2001 14:48 -0400 Keith Moore
<[email-masked]> wrote:

>... 
> right, but absent prior agreement it becomes a guessing game.
> it's  hard enough to make mail work reliability without asking
> users to  guess about which priority setting will get their
> mail through a particular MTA.

Keith,

It seems to me that there are two important cases here:

* The MTAs of concern are under the control of either the sender
or the receiver.  In this case, the "guessing game" is no worse
than the one that is played with every message: you need to
guess what "from:" and "subject" lines, and envelope address to
use to maximize the chance that I will read your mail or, put
differently, which ones to avoid to minimize the chance that I
will delete it without reading (or have agents or filters do
that for me).

* The MTAs making the decision are "in the middle", and not
under the control of either sender or recipient, or anyone both
accept as an appropriate intervening authority.   That scenario
is basically equivalent to all of the other interception objects
on the network (what you think about those is well-established;
let's not have the discussion here again), but with one major
difference -- there will be no intermediate MTAs doing stupid
things out of ignorance of the protocol, since a priority
parameter cannot be sent to any MTA that does not advertise it.
That is a small advantage for this case, although perhaps a
trivially small one.

   john

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Julian Onions <[email-masked]>, [email-masked], Graham Klyne <[email-masked]>
Subject: Re: SMTP Service Extension for Priority 
Date: Mon, 25 Jun 2001 15:58:17 -0400
Sender: [email-masked]

> This proposal appears to be directly competitive with Deliver-By (and, by
> derivation, the Timely Confirmation proposal.)

they're orthogonal, by intention.  From RFC 2852:

   This extension should *not* be viewed as a vehicle for requesting
   "priority" processing.  A receiving SMTP server may assign whatever
   processing priority it wishes to a message transmitted with a Deliver
   By request.  

(emphasis mine)

From: Keith Moore <[email-masked]>
To: John C Klensin <[email-masked]>
cc: Keith Moore <[email-masked]>, Julian Onions <[email-masked]>, [email-masked]
Subject: Re: SMTP Service Extension for Priority 
Date: Mon, 25 Jun 2001 14:48:49 -0400
Sender: [email-masked]

> I agree about the authentication issues.
> 
> That said, I have believed for years that senders ought to be
> able to assert their opinion of the importance of a message they
> are sending, and that receipients should be able filter and
> assign actions based on that information, with the understanding
> that the filters could apply the recipient's prior opinion of
> the priority-settings of the sender.  

perhaps, but that strikes me as an entirely different mechanism 
(e.g. Importance message header) than one which changes the priority 
at which a message is handled by an MTA. 

> Note that in this scenario, the authorization issue --
> "verification of the sender's privilege to set that priority" in
> your words --would not apply: senders could make any assertions
> they wished, at the risk of undermining their credibility with
> the recipient and having their priorities generally downgraded.

right, but absent prior agreement it becomes a guessing game.  it's 
hard enough to make mail work reliability without asking users to 
guess about which priority setting will get their mail through
a particular MTA.

> FWIW, I'm not comfortable about the notion of an SMTP extension
> that seems to imply utility only for a restricted community
> inventing new primary reply codes.   

IMHO new primary reply codes should be reserved for extensions that
require explicit support in the client in order to be handled
properly.  If an ordinary 500 or 400 will suffice to tell the
client how to handle the message, we don't need to add a new reply code.

Date: Mon, 25 Jun 2001 14:36:16 -0400
From: John C Klensin <[email-masked]>
Subject: Re: SMTP Service Extension for Priority
To: Keith Moore <[email-masked]>, Julian Onions <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Keith,

I agree about the authentication issues.

That said, I have believed for years that senders ought to be
able to assert their opinion of the importance of a message they
are sending, and that receipients should be able filter and
assign actions based on that information, with the understanding
that the filters could apply the recipient's prior opinion of
the priority-settings of the sender.  I.e., if you set a
priority of "5" (whatever that means), I ought to be able to
have filters structured so that I can assert (unbeknown to you)
that I think you always understimate so that any priority you
specify should be boosted by 10% (or according to some more
complex function).  Similarly, I ought to be able to downgrade
the priority assignments of selected others (in the limiting
case, setting all of someone's priorities to zero might be
equivalent to routing their mail to the bitbucket... or it might
now) and to specify handling of messages with unassigned
priorities or unauthenticated senders.  The draft seems to
anticipate some of this, since "may silently downgrade..." is
present as an option.

Note that in this scenario, the authorization issue --
"verification of the sender's privilege to set that priority" in
your words --would not apply: senders could make any assertions
they wished, at the risk of undermining their credibility with
the recipient and having their priorities generally downgraded.

However, it is not clear that the proposal is the optimal way to
provide the information I'm looking for, especially since my
scenario doesn't assume that the priority settings would
influence the behavior of any MTA other than the last one, if
that.  But the implied layering issue is subtle.  E.g., the
draft specifies that the mechanism could be used for early
refusal of some messages.   I would consider it entirely
appropriate for an receiving (final delivery) MTA, acting on my
behalf, to reject a message a RCPT time whose posterior priority
was such that there was no chance I wanted to look at it, ever.
Of course, this would have no impact on any intermediate MTAs
unless, through some capability negotiation, I could propagate
my prior preferences backward toward the sender.

FWIW, I'm not comfortable about the notion of an SMTP extension
that seems to imply utility only for a restricted community
inventing new primary reply codes.   Use of a code in the RFC
1893 style would seem far more attractive, especially since both
client and server would need to understand the priority
extension for the proposed error statuses to arise.

   john

--On Monday, 25 June, 2001 13:37 -0400 Keith Moore
<[email-masked]> wrote:

> 
>> Appreciate any comments,
> 
> Basically I think a mechanism such as this is useless w/o
> requiring  authentication of the sender (which could be done
> by SMTP AUTH) and  verification of the sender's privilege to
> set that priority.   And that only works for the first hop.  I
> think we would also need some  sort of model for determining
> priority of messages on subsequent hops -  based on either the
>...

To: Dave Crocker <[email-masked]>
Cc: Julian Onions <[email-masked]>, [email-masked], Graham Klyne <[email-masked]>
Subject: Re: SMTP Service Extension for Priority 
From: [email-masked]
Date: Mon, 25 Jun 2001 14:14:09 -0400
Sender: [email-masked]

--==_Exmh_870257815P
Content-Type: text/plain; charset=us-ascii

On Sun, 24 Jun 2001 13:59:27 EDT, Dave Crocker said:
> This proposal appears to be directly competitive with Deliver-By (and, by 
> derivation, the Timely Confirmation proposal.)

It's not *directly* competitive.

I may use Delivery-By: if it's time-critical ("Hey George, lunch at Blue River
Cafe at 12:30?") and can be discarded if the time constraint isn't met. In
this case, I don't care about order, I just care if *THIS* mail gets there
by a specific time or not.

Priority sorting is a different issue.  For instance, I run one of the larger
Listserv sites in the world, and the ability to specify *relative* priorities
would be useful in cases of congestion (for instance, tagging "local" or
"paid" or "postmaster/admin" addresses for handle-this-first).  In this case,
I don't care about the exact time an item is handled, I merely wish to make
sure that certain classes of recipient are at least attempted first (of
course, if my "paid" subscriber's host is down, it should go on and try
something else).
-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

--==_Exmh_870257815P
Content-Type: application/pgp-signature

--==_Exmh_870257815P--

Date: Sun, 24 Jun 2001 13:59:27 -0400
To: Julian Onions <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: SMTP Service Extension for Priority
Cc: [email-masked], Graham Klyne <[email-masked]>
Sender: [email-masked]

This proposal appears to be directly competitive with Deliver-By (and, by 
derivation, the Timely Confirmation proposal.)

The problem with simple 'priority' labeling is that it is not possible to 
predict actual system performance.

d/

At 12:02 PM 6/25/2001, Julian Onions wrote:
>A proposed method for passing priority of the message, per recipient
>as part of the SMTP protocol to allow support for military messaging and
>early rejection or temporary refusal based on the priority given.
>
>http://www.ietf.org/internet-drafts/draft-onions-priority-smtpext-00.txt

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

From: Keith Moore <[email-masked]>
To: Julian Onions <[email-masked]>
cc: [email-masked]
Subject: Re: SMTP Service Extension for Priority 
Date: Mon, 25 Jun 2001 13:37:06 -0400
Sender: [email-masked]

> Appreciate any comments,

Basically I think a mechanism such as this is useless w/o requiring 
authentication of the sender (which could be done by SMTP AUTH) and 
verification of the sender's privilege to set that priority.  
And that only works for the first hop.  I think we would also need some 
sort of model for determining priority of messages on subsequent hops - 
based on either the sender's authenticated identity or on the identity 
of the MTA that relayed the message.

Also, there is a potential problem with the negotiation - the fact
that an SMTP server asserts that it supports the priority extension
does not imply that the client/sender has the right credentials to 
request priority handling from that server.  If the client doesn't
have the right credentials, the worst that the servers should do is
to assign a priority equal to that of a message that does not assert
a priority.  So a message should not be refused or delayed relative
to an unprioritized message simply because the client attempted to 
assert a priority.

The draft doesn't say anything about what happens to priority when 
a message is relayed.  I guess that the priority should also be
relayed (if possible) but the draft should say so explicity.

Keith

Date: Mon, 25 Jun 2001 12:56:09 -0400
From: John C Klensin <[email-masked]>
Subject: Re: CRAM - MD5
To: Koti <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

--On Monday, 25 June, 2001 18:22 +0530 Koti
<[email-masked]> wrote:

> Ref: CRAM-MD5, challenge reply authentication mechanisam RFC
> 2195.
> 
> Hi,
> 
> 1. How client & server maintain shared secret?

Any way they like.  This is deliberately not specified in the
standard.

   john

Date: Mon, 25 Jun 2001 09:09:08 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re:
Sender: [email-masked]

At 12:36 PM +0530 6/25/01, Koti wrote:
>Where can i get SMTP RFCs?

See <http://www.imc.org/rfc2821>.

--Paul Hoffman, Director
--Internet Mail Consortium

To: [email-masked]
Subject: SMTP Service Extension for Priority
Date: Mon, 25 Jun 2001 17:02:21 BST
From: Julian Onions <[email-masked]>
Sender: [email-masked]

A proposed method for passing priority of the message, per recipient
as part of the SMTP protocol to allow support for military messaging and
early rejection or temporary refusal based on the priority given.

http://www.ietf.org/internet-drafts/draft-onions-priority-smtpext-00.txt

Appreciate any comments,
Julian.

From: "Koti" <[email-masked]>
To: <[email-masked]>
Subject: CRAM - MD5
Date: Mon, 25 Jun 2001 18:22:20 +0530
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0146_01C0FDA3.C5752820
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Ref: CRAM-MD5, challenge reply authentication mechanisam RFC 2195.

Hi,

1. How client & server maintain shared secret?

- Koti
Off: 040 6513274 Extn: 8842
----------------------------------------------------------------
When one door of happiness closes, another opens; but often we look so =
long at the closed door=20
that we do not see the one, which has opened for us. - Hellen Keller.

------=_NextPart_000_0146_01C0FDA3.C5752820
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Ref: CRAM-MD5, challenge reply authentication mechanisam RFC =
2195.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>1. How client &amp; server maintain shared secret?</DIV>
<DIV>&nbsp;</DIV>
<DIV><BR>- Koti<BR>Off: 040 6513274 Extn:=20
8842<BR>----------------------------------------------------------------<=
BR>When=20
one door of happiness closes, another opens; but often we look so long =
at the=20
closed door <BR>that we do not see the one, which has opened for us. - =
Hellen=20
Keller.<BR></DIV></BODY></HTML>

------=_NextPart_000_0146_01C0FDA3.C5752820--

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

From: "Koti" <[email-masked]>
To: <[email-masked]>
Subject: 
Date: Mon, 25 Jun 2001 12:36:41 +0530
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00B8_01C0FD73.7C7D59B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

Where can i get SMTP RFCs?
=20
Thanks,
- Koti
Off: 040 6513274 Extn: 8842
----------------------------------------------------------------
When one door of happiness closes, another opens; but often we look so =
long at the closed door=20
that we do not see the one, which has opened for us. - Hellen Keller.

------=_NextPart_000_00B8_01C0FD73.7C7D59B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Where can i get SMTP RFCs?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks,<BR>- Koti<BR>Off: 040 6513274 Extn:=20
8842<BR>----------------------------------------------------------------<=
BR>When=20
one door of happiness closes, another opens; but often we look so long =
at the=20
closed door <BR>that we do not see the one, which has opened for us. - =
Hellen=20
Keller.<BR></DIV></BODY></HTML>

------=_NextPart_000_00B8_01C0FD73.7C7D59B0--

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: Keith Moore <[email-masked]>, Blake Ramsdell <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: IANA SMTP registry 
Date: Mon, 25 Jun 2001 00:45:45 -0400
Sender: [email-masked]

> > why are they listed at all?  I thought SMTP extensions had to be either
> > standards-track or experimental with explicit IESG approval.
> 
> I think those two snuck in as "de facto" - they were in Sendmail, Sendmail
> had a 70-90% market base, soooo..... ;)

yes but there was an explicit WG decision to NOT register such codes.

To: Keith Moore <[email-masked]>
cc: Blake Ramsdell <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: IANA SMTP registry 
From: [email-masked]
Date: Mon, 25 Jun 2001 00:35:05 -0400
Sender: [email-masked]

On Sun, 24 Jun 2001 21:54:43 EDT, Keith Moore said:
> 
> > 4. The keywords VERB and ONEX have "Eric Allman" listed as a reference, but
> > I have no idea how to dereference it (yes, I know who Allman is and I can
> > scrounge up his email address, but isn't the spirit of this to be able to
> > have a publicly available specification, more specifically, an RFC?)
> 
> why are they listed at all?  I thought SMTP extensions had to be either
> standards-track or experimental with explicit IESG approval. 

I think those two snuck in as "de facto" - they were in Sendmail, Sendmail
had a 70-90% market base, soooo..... ;)

/Valdis

From: Keith Moore <[email-masked]>
To: "Blake Ramsdell" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: IANA SMTP registry 
Date: Sun, 24 Jun 2001 21:54:43 -0400
Sender: [email-masked]

> 4. The keywords VERB and ONEX have "Eric Allman" listed as a reference, but
> I have no idea how to dereference it (yes, I know who Allman is and I can
> scrounge up his email address, but isn't the spirit of this to be able to
> have a publicly available specification, more specifically, an RFC?)

why are they listed at all?  I thought SMTP extensions had to be either
standards-track or experimental with explicit IESG approval. 

Keith

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: IANA SMTP registry
Date: Sun, 24 Jun 2001 17:51:13 -0700
Sender: [email-masked]

My understanding is that: 

http://www.isi.edu/in-notes/iana/assignments/mail-parameters 

should have all of the SMTP service extensions listed (RFC2821 section
2.2.2)

1. The AUTH EHLO keyword and AUTH verb are not listed (RFC2554 Section 3) 

2. The TCP VIA link type is not listed (RFC2821 Section 4.4) 

3. Should references to RFCs 821 and 822 to be updated to 2821 and 2822? 

4. The keywords VERB and ONEX have "Eric Allman" listed as a reference, but
I have no idea how to dereference it (yes, I know who Allman is and I can
scrounge up his email address, but isn't the spirit of this to be able to
have a publicly available specification, more specifically, an RFC?)

I don't know who to send these to, so this is both a sanity check (the
things I point out may not be things that are required to be in the
registry, though it would be nice to have all of the EHLO keywords
somewhere, and I presume that was the spirit of this page), and a "who
should I send this to?" message.

Blake

Date: Tue, 19 Jun 2001 16:14:11 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Fwd: Last Call: SMTP Service Extension for Secure SMTP over TLS to 	 Proposed Standard
Sender: [email-masked]

>To: IETF-Announce: ;
>From: The IESG <[email-masked]>
>SUBJECT: Last Call: SMTP Service Extension for Secure SMTP over TLS to
>	Proposed Standard
>Reply-to: [email-masked]
>Date: Tue, 19 Jun 2001 16:35:16 -0400
>Sender: [email-masked]
>
>
>The IESG has received a request to consider SMTP Service Extension for
>Secure SMTP over TLS <draft-hoffman-rfc2487bis-05.txt> as a Proposed
>Standard.  This has been reviewed in the IETF but is not the product of
>an IETF Working Group.
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send any comments to the
>[email-masked] or [email-masked] mailing lists by July 19, 2001.
>
>Files can be obtained via
>http://www.ietf.org/internet-drafts/draft-hoffman-rfc2487bis-05.txt

Date: 	Mon, 18 Jun 2001 12:15:32 +0300
From: Matti Aarnio <[email-masked]>
To: John Martin <[email-masked]>
Cc: [email-masked]
Subject: Re: stupid SMTP rejection of spammers
Sender: [email-masked]

On Fri, Jun 15, 2001 at 08:00:47PM +0200, John Martin wrote:
> At 01:07 PM 15/06/01 -0400, Keith Moore wrote:
> > >>> MAIL FROM:<>
> >572 Bounces are blocked due to system abuse by spammers
> > >>> MAIL FROM:<[email-masked]>
> >250 Sender OK
> 
> Is there any correlation to smtp software being used? (Is it possible to tell?)
> John

  I think I saw this practice at first at (ISP) systems running qmail
  derived software.  There is some simple way to configure undesired
  source addresses into a black-list, including "the box".

  Latter the practice has spread...

-- 
/Matti Aarnio	<[email-masked]>

Date: 	Sat, 16 Jun 2001 12:59:21 +0300
From: Matti Aarnio <[email-masked]>
To: [email-masked]
Subject: Re: stupid SMTP rejection of spammers
Sender: [email-masked]

On Fri, Jun 15, 2001 at 01:42:59PM -0500, Chip Rosenthal wrote:
....
> Sorry if I'm not being productive.  I'm irritated at broken mail
> software, and I'm irritated that we need to produce an "RFC For Dummies"
> document for the authors of said software.
> 
> Hmmm ... I wonder if producing a conformance suite might be a solution
> to this problem.

   Perhaps it would.   The audience of such document isn't exactly
the software authors, but the hordes of clueless sysadmins who do
all kinds of weird (and wrong) things with the software.

> -- 
> Chip Rosenthal              The First Amendment doesn't give you the right
> http://www.unicom.com/    to talk during a movie.  Why does the junk email
> <[email-masked]>           lobby believe it gives them the right to spam?

-- 
/Matti Aarnio	<[email-masked]>

Date: Sat, 16 Jun 2001 10:55:50 +0200
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Re: stupid SMTP rejection of spammers
Sender: [email-masked]

At 14.02 -0400 01-06-15, Keith Moore wrote:
>  > Start by writing a paper about "BCP of SMTP operation".
>>
>>  (1) Don't block empty envelope from:
>>  (2) Don't say ok to a recipient address if you are not 
>>100% sure you can do
>>  local delivery.
>>  (3) ...
>>
>
>any others that folks want to contribute?
>
>Keith

Loop control could be discussed, but there may be difficulty
to reach consensus, since there are different techniques which
all work (and can be combined for increased reliability).

See the quote at the end of this e-mail from my
not-yet-published book about application layer protocols. You
have my permission to use part of this text. Loop control
can of course be needed also without mailing lists,
especially when Sendmail aliases are used or other
auto-retransmission tools.

Should your document on SMTP behaviour:

(a) Incorporate my paper about mailing list behaviour,
     see http://dsv.su.se/jpalme/ietf/mailing-list-behaviour.txt

(b) Leave mailing list behaviour to my paper.

(c) Duplicate information from my mailing list behaviour
     paper.

You are free to use the content of my paper on mailing
list behaviour.

--- --- quote from not-yet-published-book --- ---

1.12.2 Loop control for nested mailing lists

If two lists are directly or indirectly members of each
other, there is a risk that the same message will be looped
back and forward indefinitely between the lists. There are
several different techniques for avoiding this:

(1)	Full expansion by the originating UA.

(2a)	A trace list of all the mailing lists passed is put
on the envelope of the message. A mailing list can then
refuse to accept, incoming messages, that have the name of
the mailing list itself as part of the trace list on the
envelope of the message.

(2b)	Using a variant of method (2a), each mailing list
will instead refuse to send a message to another mailing list
which is included in the trace list of the message.

(3)	The registration system for mailing lists is designed
in such a way that no list will ever be a member, directly or
indirectly, of itself.

(4a)	Each mailing list stores the message-IDs of all
messages passing through
the list. When the same message returns once more to the
list, the list checks the message-ID of the message and stops
the loop if a message with the same ID has already passed
through the list. (Message-ID is also known under the term
Message-ID.)

(4b)	This is a variant of method (4a), where a checksum of
the content of the message is used instead of the message-ID.

The X.400 standard for electronic mail uses method (2a) and
recommends use of method (2b) as an addition to (but not as a
replacement for) method (2a). The advantage of method (2b)
is that it saves some unnecessary transmission. However,
method (2b) is not as reliable as method (2a), because the
same electronic mail address can have different forms, and
therefore the comparison used in method (2b) may not work. It
is easier for a list expander to recognize a name which it
itself puts on an envelope than a name which some other list
expander puts on an envelope.

Comparing methods (4a) and (4b), method (4b), use of a
checksum, has the advantage that it caters for systems where
the message-ID is corrupted (something which is not unusual),
but has as a disadvantage that two different messages may
accidentally get the same checksum. A further problem with
the message-ID is that two messages with the same message-ID
may not always be identical. Finally, some mail systems to
not generate globally unique message-IDs on the messages
they produce.

Method (4a) is often used by computer conferencing systems,
sometimes combined with the other methods. For example,
Usenet News mainly uses method (4a).
Programs that send messages through gateways from Internet
e-mail to Usenet News will assign Message-IDs to messages
lacking such IDs. This can cause the same message to get
different Message-IDs by different gateways.

The Listserv software has very powerful methods for avoiding
loops, primarily based on method (4b).

In practice, many existing mailing lists have no loop control
mechanism except that the people who manage the list manually
try to avoid producing loops.

-- 
--
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

To: [email-masked]
Subject: Re: stupid SMTP rejection of spammers
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: 15 Jun 2001 14:48:35 -0700
Lines: 37
Sender: [email-masked]

Patrik Fältström <[email-masked]> writes:

> But, what I have been forced to help some large companies in Sweden with
> is a setup when they have one mail host which the MX refer to, and that
> host accept any local part (but only their domainname). The host is then
> relaying the mail to some internal host(s) which might give back a 5xx
> response. The bounce is going to the envelope sender address, which is
> the real target for something which can be seen as something between DOS
> and spam attack.

I'm pretty strongly of the opinion that this is a valid e-mail
configuration.  It's unfortunate that it opens up the possibility of a
mailbomb by proxy, but under most circumstances it doesn't serve as a
mangifier, and therefore really isn't much worse than a direct mailbomb.
Most anything you can do this way you can also do by just mailing the
victim directly, so as long as there are full trace headers included, I
don't see a significant increase in abuse potential.

SMTP is inherently abuseable by design, unfortunately.

There are good reasons to want to accept the mail and generate a separate
bounce rather than denying the message at the SMTP layer.  One reason is
security partitioning on the mail server; if you want to make the
network-exposed code as simple as possible, putting in code to determine
what addresses are valid in an arbitrarily complex and fast-changing
system behind the listern probably isn't a good idea.  Another reason is
to return more information than is possible with a 550 error at the SMTP
level, such as providing near-match directory information against the set
of directory entries where the user has chosen to make that information
public (this is what we do).

I do agree that such systems should have rate limiting on the bounces
they're willing to send back, but saying that it's an inherently bad mail
design goes too far in my experience.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Fri, 15 Jun 2001 23:34:03 +0200
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: Russ Allbery <[email-masked]>, [email-masked]
Subject: Re: stupid SMTP rejection of spammers
Sender: [email-masked]

--On 01-06-15 14.20 -0700 Russ Allbery <[email-masked]> wrote:

> Patrik Fältström <[email-masked]> writes:
> 
>> (2) Don't say ok to a recipient address if you are not 100% sure you can
>> do local delivery.
> 
> This is not best current practice in many situations, the most obvious
> being relays, gateways, and backup MX hosts.  This argument came up on
> DRUMS too; hopefully it won't be necessary to rehash it again.  There is
> no consensus in favor of this position.

Agreed there are a number of cases in normal design of networks this is ok.

But, what I have been forced to help some large companies in Sweden with is
a setup when they have one mail host which the MX refer to, and that host
accept any local part (but only their domainname). The host is then
relaying the mail to some internal host(s) which might give back a 5xx
response. The bounce is going to the envelope sender address, which is the
real target for something which can be seen as something between DOS and
spam attack.

Not fun.

   paf

To: [email-masked]
Subject: Re: stupid SMTP rejection of spammers
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: 15 Jun 2001 14:20:58 -0700
Lines: 12
Sender: [email-masked]

Patrik Fältström <[email-masked]> writes:

> (2) Don't say ok to a recipient address if you are not 100% sure you can
> do local delivery.

This is not best current practice in many situations, the most obvious
being relays, gateways, and backup MX hosts.  This argument came up on
DRUMS too; hopefully it won't be necessary to rehash it again.  There is
no consensus in favor of this position.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Fri, 15 Jun 2001 21:00:22 +0200
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: [email-masked]
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: stupid SMTP rejection of spammers 
Sender: [email-masked]

--On 01-06-15 14.34 -0400 [email-masked] wrote:

> On Fri, 15 Jun 2001 19:48:05 +0200, =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=
> said:
> 
>> Start by writing a paper about "BCP of SMTP operation".
>> 
>> (1) Don't block empty envelope from:
>> (2) Don't say ok to a recipient address if you are not 100% sure you can
>> do local delivery.
> 
> You're preaching to the choir, Patrik. ;)

I know :-)

My point was that maybe a shorter document which talks more explicit about
the do and don't in 2821 and 2822, that would be easy to give to operations.

I don't know if I am right or not.

   paf

Date: Fri, 15 Jun 2001 15:56:49 -0400 (Eastern Daylight Time)
From: Todd Vierling <[email-masked]>
To: "Rolf E. Sonneveld" <[email-masked]>
cc: <[email-masked]>
Subject: Re: stupid SMTP rejection of spammers
Sender: [email-masked]

On Fri, 15 Jun 2001, Rolf E. Sonneveld wrote:

: > > (1) Don't block empty envelope from:
: > > (2) Don't say ok to a recipient address if you are not 100% sure you can do
: > > local delivery.

: (3) don't reject mail if you are listed as MX host
: (4) always support postmaster@domain, for all domains for which you send mail to
: the Internet.

One interesting thing to note is that there's already a blackhole project
intended to combat some of this:  it allows a MTA to autobounce mail from
RFC-ignorant domains (that is, domains for which the MXs violate either 1 or
4 above).  The list is arranged as a *domain*-based (not IP-based) DNS zone.

See:  http://www.rfc-ignorant.org/

-- 
-- Todd Vierling ([email-masked])

From: "Dan Wing" <[email-masked]>
To: "Keith Moore" <[email-masked]>, =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Cc: <[email-masked]>
Subject: RE: stupid SMTP rejection of spammers 
Date: Fri, 15 Jun 2001 12:57:49 -0700
Importance: Normal
Sender: [email-masked]

> > Start by writing a paper about "BCP of SMTP operation".
> >
> > (1) Don't block empty envelope from:
> > (2) Don't say ok to a recipient address if you are not 100% sure
> you can do
> > local delivery.
> > (3) ...
> >
>
> any others that folks want to contribute?

Don't emit MAIL FROMs that are non-replyable.  Kind of goes without saying,
but it happens all the time.

Perhaps this BCP could include a discussion on recommended 'vacation'
behavior, as well.

-d

From: Keith Moore <[email-masked]>
To: Chip Rosenthal <[email-masked]>
cc: [email-masked]
Subject: Re: stupid SMTP rejection of spammers 
Date: Fri, 15 Jun 2001 15:46:49 -0400
Sender: [email-masked]

> I'm irritated at broken mail
> software, and I'm irritated that we need to produce an "RFC For Dummies"
> document for the authors of said software.

me too.  and of course we could always write a new RFC that says
"do what this other RFC says".  it might even be useful to present
the information in a different form  - sometimes that makes it
easier for the audience to understand.

but perhaps there are other mechanisms also?  maybe we can get vendors 
to mention this in their documentation, or to tell their tech support
people about it?  maybe we really do need an "SMTP for dummies" book?

Keith

Date: Fri, 15 Jun 2001 21:01:26 +0200
From: "Rolf E. Sonneveld" <[email-masked]>
Subject: Re: stupid SMTP rejection of spammers
To: Keith Moore <[email-masked]>
Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>, [email-masked]
Organization: Sonnection B.V.
Sender: [email-masked]

Hi, Keith

Keith Moore wrote:

> > Start by writing a paper about "BCP of SMTP operation".
> >
> > (1) Don't block empty envelope from:
> > (2) Don't say ok to a recipient address if you are not 100% sure you can do
> > local delivery.
> > (3) ...
> >
>
> any others that folks want to contribute?

Yes, certainly. Like you, I noticed a substantial increase of the blocking of
empty envelope from addresses, which worried me.

Apart from that, I noticed during the last couple of months (doing postmaster
duties for a company) that more and more MX-listed systems are misconfigured and
reject mail with SMTP 5xx status responses telling that they won't relay for that
domain.

I can easily show a number of these rejections. The annoying thing is, that when
I try to send mail to postmaster@domain or postmaster@Mx-listed host, these
messages also are rejected with the same message.

So please ad:

(3) don't reject mail if you are listed as MX host
(4) always support postmaster@domain, for all domains for which you send mail to
the Internet.

BTW: I wouldn't name it a BCP, since most of the above items are clearly stated
as requirements in RFC's. So I would call it an informational RFC (or what's the
name for such an RFC?), like there is also an RFC stating common configuration
errors in DNS/Bind (I don't remember the RFC number, but I believe Piet Beertema,
CWI has contributed to it).

Regards,

/rolf

Date: Fri, 15 Jun 2001 13:42:59 -0500
From: Chip Rosenthal <[email-masked]>
To: [email-masked]
Subject: Re: stupid SMTP rejection of spammers
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Fri, Jun 15, 2001 at 02:02:00PM -0400, Keith Moore wrote:
> any others that folks want to contribute?

Yes.  Each proposed criterion is roughly equivalent to:  "Don't
violate RFC 2821."

Maybe we can boil this down to a one-liner:  Please don't write mail
software if you can't understand the fscking specs.

Sorry if I'm not being productive.  I'm irritated at broken mail
software, and I'm irritated that we need to produce an "RFC For Dummies"
document for the authors of said software.

Hmmm ... I wonder if producing a conformance suite might be a solution
to this problem.

-- 
Chip Rosenthal              The First Amendment doesn't give you the right
http://www.unicom.com/    to talk during a movie.  Why does the junk email
<[email-masked]>           lobby believe it gives them the right to spam?

To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: stupid SMTP rejection of spammers 
From: [email-masked]
Date: Fri, 15 Jun 2001 14:34:53 -0400
Sender: [email-masked]

--==_Exmh_896675387P
Content-Type: text/plain; charset=us-ascii

On Fri, 15 Jun 2001 19:48:05 +0200, =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= said:

> Start by writing a paper about "BCP of SMTP operation".
> 
> (1) Don't block empty envelope from:
> (2) Don't say ok to a recipient address if you are not 100% sure you can do
> local delivery.

You're preaching to the choir, Patrik. ;)

(1) and (2) are/were both required all the way back in RFC821, as amended
by RFC1123. (Actually, the requirement for (2) is "unless you are 100% sure
you can either deliver or forward" - think about the case of a front-end
to a mail cluster at a large site),

If the <bleep>heads won't follow RFC821/1123, why do you expect they'd
pay any attention to a new BCP?

(technical note here - LSoft's Listserv product generates mail that has
an origin of <> for all its  automatically generated replies to subscribe
requests and so on - mail posted "from a list" goes out with an owner-
address)

Personally, I have a little hook into EXMH, that whenever my Listserv machine
bounces me a mail that got rejected because the other end rejects <>,
I just hit a key and forward the mail to [email-masked]', along
with a copy to the user, so maybe the *user* will yell at the admin for
running a broken mailer and causing them to fix things.

I've appended my canned message, if anybody cares...

-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech
--- start canned message
:We attempted to send mail to your site, which rejected it on the
:grounds that it had a null reverse path in the MAIL FROM: SMTP
:command.  'MAIL FROM:<>' is how other systems send your system error
:notifications.  Refusing to accept them means that your users will
:never know if their mail was handled sucessfully.
:
:Usually, null reverse paths are refused because of a misguided attempt to
:stop "spammers" from sending mail through your site.  There are other,
:better ways to address this problem.
:
:Mail software known to be affected:
:
:Port 25 banner:
:220 X1 NT-ESMTP Server your.host.here (IMail 4.04 21974-1)
:  This software incorrectly gives a '501 bogus mail from' error.
:
:Port 25 banner:
:
:  This software incorrectly gives a '550 Access denied' error.
:
:The relevant sections of the Internet RFC standards and a copy of
:the rejected mail follow.
:
:RFC821, section 3.6 says:
:
:      This notification message must be from the server-SMTP at this
:      host.  Of course, server-SMTPs should not send notification
:      messages about problems with notification messages.  One way to
:      prevent loops in error reporting is to specify a null reverse-path
:      in the MAIL command of a notification message.  When such a
:      message is relayed it is permissible to leave the reverse-path
:      null.  A MAIL command with a null reverse-path appears as follows:
:
:         MAIL FROM:<>
:
:RFC1123, section 5.2.9 says:
:
:      5.2.9  Command Syntax: RFC-821 Section 4.1.2
:
:         The syntax shown in RFC-821 for the MAIL FROM: command omits
:         the case of an empty path:  "MAIL FROM: <>" (see RFC-821 Page
:         15).  An empty reverse path MUST be supported.
:
:RFC1123, section 5.3.3 says:
:
:         If there is a delivery failure after acceptance of a message,
:         the receiver-SMTP MUST formulate and mail a notification
:         message.  This notification MUST be sent using a null ("<>")
:         reverse path in the envelope; see Section 3.6 of RFC-821.  The
:         recipient of this notification SHOULD be the address from the
:         envelope return path (or the Return-Path: line).  However, if
:         this address is null ("<>"),  the receiver-SMTP MUST NOT send a
:         notification.  If the address is an explicit source route, it
:         SHOULD be stripped down to its final hop.
:
:				Valdis Kletnieks
:				Computer Systems Senior Engineer
:				Virginia Tech

--==_Exmh_896675387P
Content-Type: application/pgp-signature

--==_Exmh_896675387P--

Date: Fri, 15 Jun 2001 20:32:00 +0200
To: James M Galvin <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: vacation replies to From: or envelope from
Cc: Keith Moore <[email-masked]>, [email-masked]
Sender: [email-masked]

At 11.02 -0400 01-04-03, James M Galvin wrote:
>While I accept your point of view as valid, let me say more 
>about why I
>don't agree with it.
>
>The issue, as I see it, is being clear about when a message has been
>delivered and at what point in the infrastructure we are 
>taking action.
>
>The standards that define how to use DNSs today all speak to 
>the status
>of getting a message to its message store.  A message is considered
>delivered if it gets there and it is the MTA that is 
>responsible for all
>the action.
>
>Vacation notices, in my opinion, are a user agent issue. 
>The fact that
>an MTA is executing the "vacation" program on behalf of a 
>user or their
>agent does not change the fact that the "delivery has been completed"
>and the MTA responsibility has at least conceptually ended.  Once you
>cross that line the envelope information is not what's 
>important, it is
>the message information that is important.

There are different kinds of mailing lists. For large mailing
lists, where the contributor may not even know the names of
all the members, vacation-notices like non-delivery messages
should go to the list maintainer.

For small, closed groups, it is usually more appropriate for
the vacation notices to go to the contributor, and possibly
also with a copy to the list maintainer.

Since it is difficult for a recipient mailer or a
vacation-notice-sender to know, whether a mailing list is of
type 1 or type 2, the proper behaviour is to always send it
to the SMTP sender. It is the task of the mailing list
software to set this appropriately. For example, most large
mailing list maintainer softwares like "Listserv" set the
SMTP sender to the list maintainer.

Smaller closed lists are often created using the alias
functionality in Sendmail, and then the SMTP sender will be
the author of the contribution.

-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

From: Keith Moore <[email-masked]>
To: John Martin <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: stupid SMTP rejection of spammers 
Date: Fri, 15 Jun 2001 14:17:01 -0400
Sender: [email-masked]

> Is there any correlation to smtp software being used? (Is it possible to tell?)

I haven't noticed any. Certainly it's possible to configure many mailers to work this way.

From: Keith Moore <[email-masked]>
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: stupid SMTP rejection of spammers 
Date: Fri, 15 Jun 2001 14:02:00 -0400
Sender: [email-masked]

> Start by writing a paper about "BCP of SMTP operation".
> 
> (1) Don't block empty envelope from:
> (2) Don't say ok to a recipient address if you are not 100% sure you can do
> local delivery.
> (3) ...
> 

any others that folks want to contribute?

Keith

Date: Fri, 15 Jun 2001 20:00:47 +0200
To: Keith Moore <[email-masked]>, [email-masked]
From: John Martin <[email-masked]>
Subject: Re: stupid SMTP rejection of spammers
Cc: [email-masked]
Sender: [email-masked]

At 01:07 PM 15/06/01 -0400, Keith Moore wrote:
> >>> MAIL FROM:<>
>572 Bounces are blocked due to system abuse by spammers
> >>> MAIL FROM:<[email-masked]>
>250 Sender OK

Is there any correlation to smtp software being used? (Is it possible to tell?)

John

---------------------------------------------------------------
Network Appliance           Direct / Voicemail: +31 23 567 9615
Scorpius 2                                 Fax: +31 23 567 9699
NL-2132 LR Hoofddorp               Main Office: +31 23 567 9600
---------------------------------------------------------------

Date: Fri, 15 Jun 2001 19:48:05 +0200
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: Keith Moore <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: stupid SMTP rejection of spammers
Sender: [email-masked]

--On 01-06-15 13.07 -0400 Keith Moore <[email-masked]> wrote:

> is there anything that can be done to discourage this practice, or provide
> better countermeasures?  

Start by writing a paper about "BCP of SMTP operation".

(1) Don't block empty envelope from:
(2) Don't say ok to a recipient address if you are not 100% sure you can do
local delivery.
(3) ...

    paf

To: [email-masked]
Subject: stupid SMTP rejection of spammers
cc: [email-masked]
From: Keith Moore <[email-masked]>
Date: Fri, 15 Jun 2001 13:07:46 -0400
Sender: [email-masked]

background: I maintain my mailing lists "by hand", which is to say that I read 
subscription requests personally and use shell scripts to add/delete people
from lists.  part of what the "add2list" script does is run a verification
program to make sure the subscriber address is valid - that program parses
the address, looks up the MX records, and tries to verify the recipient via
SMTP using HELO/MAIL/RCPT/RSET/QUIT.  

increasingly I'm seeing something like the following:

>>> MAIL FROM:<>
572 Bounces are blocked due to system abuse by spammers
>>> MAIL FROM:<[email-masked]>
250 Sender OK

(several years ago, I modified the verification program to try MAILER-DAEMON
if <> wasn't accepted.  but only recently has this practice become widespread)

to me this seems completely shortsighted brain damaged.   

first of all, it doesn't do anything to deter spam, it only keeps the 
site that the spammer puts in the return address from realizing that the
spammer has used the site in that way.

second, it prevents legitimate error messages from being returned to senders.

third, it encourages mailers to send bounces with some other return address
than <>, and thus encourages bounce loops.  

is there anything that can be done to discourage this practice, or provide
better countermeasures?  

for instance, 

- could a mailer count the number of bounces sent to each
  address, and reject bounces over so many per period of time (day? hour?)?

e.g.

>>> MAIL FROM:<>
<<< 250 OK
>>> RCPT TO:<[email-masked]>
<<< 4xx Too many bounces sent to this address, try again later

- one complaint seems to be that the volume of bounces gets so large that it
  overwhelms the mail system.  (shouldn't the mail system throttle its input?)

  perhaps mailers could perform RED on bounces?

>>> MAIL FROM:<>
<<< 4xx-we've processed too many bounces in the last hour, and this threatens to
<<< 4xx-block other kinds of messages.  so for now we're only accepting a small
<<< 4xx percentage of the bounces we receive.  please try again later.  

- seems like per-recipient quotas, if enforced at SMTP time, would also help.

Keith