headers
Dave Crocker | 1 Jul 2001 19:07

Re: SMTP QoS


At 03:54 AM 6/29/2001, Valdis.Kletnieks <at> vt.edu wrote:
>Would you favor/suggest that this be re-cast as an option for message
>posting?

The current proposal is for SMTP.  The way that a posting user gets to 
specify an SMTP option is a human factors issue that outside the scope of 
the IETF (unless we also decide that the information should be encoded in 
RFC 2822 headers.)

At 04:16 AM 6/29/2001, ned+ietf-smtp <at> mrochek.com wrote:
>>1.      As stated, the option leaves senders with an incentive to always
>>set high priority.  It costs them nothing to do this.
>
>Even if you assume this is true (past experience with priority facilities
>indicates it is not),

The past experience you have been citing pertains to LOWER priority.  That 
is quite different from one which includes HIGHER priority.

One more time:  For a service that imposes no costs on the requester, the 
incentive is to always ask for higher priority.  As I noted, we have well 
seen that the Internet is now under the strong influence of selfish 
actors.  They do not participate as good neighbors.  That is the reason we 
needed a major generational upgrade to router queuing and it is the reason 
that the proposed mechanism, here, suffers scaling limitations for the open 
Internet.

>this ignores the need to lower as well as raise priority.
(Continue reading)

Permalink | Reply | 0 comments |
headers
ned+ietf-smtp | 2 Jul 2001 00:07

Re: SMTP QoS


> At 03:54 AM 6/29/2001, Valdis.Kletnieks <at> vt.edu wrote:
> >Would you favor/suggest that this be re-cast as an option for message
> >posting?

> The current proposal is for SMTP.

And SMTP is the basis for the one submission (posting) protocol we have (RFC
276). "Recast" is therefore a bit of a stretch -- it is simply a matter of
profiling where the extension is (or is not) to be used.

> The way that a posting user gets to
> specify an SMTP option is a human factors issue that outside the scope of
> the IETF (unless we also decide that the information should be encoded in
> RFC 2822 headers.)

On the contrary, posting is a standardized function based on SMTP. And this is
true both in theory and in practice -- various posting APIs failed to pick up
NOTARY support in a timely fashion so many if not most MUAs elected to
transition to SMTP as means of submitting messages.

Now, none of this implies that priority cannot be carried in a header. It can
be, although I will argue below that it should not be. But not because only
headers are available as part of a posting mechanism. That's simply not the
case.

> > > 1.      As stated, the option leaves senders with an incentive to always
> > >         set high priority.  It costs them nothing to do this.

> > Even if you assume this is true (past experience with priority facilities
(Continue reading)

Permalink | Reply | 8 comments |
headers
Eric Allman | 2 Jul 2001 20:58
Picon

Re: IANA SMTP registry


FWIW, even Allman thinks that these shouldn't be listed, at least without
a proper definition in some RFC.  As I recall, I did send in something of
this form at some point to some one (it was enough years ago that I can't
recall any details), but those clearly didn't get published.

eric

============= In Reply To: ===========================================
: From:  ned.freed <at> mrochek.com
: Subject:  RE: IANA SMTP registry
: Date:  Thu, 28 Jun 2001 20:14:53 -0700 (PDT)

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

Permalink | Reply | 0 comments |
headers
D. J. Bernstein | 3 Jul 2001 01:10
Picon

Re: SMTP QoS


Here's a quote from the sendmail release notes in 1996: ``Conditions
were reversed for the Priority: header, resulting in all values being
interpreted as non-urgent except for non-urgent, which was interpreted
as normal.''

How long did this bug go unnoticed? Ten years? Fifteen years? And we're
supposed to believe that priority is a useful feature?

I prefer to have all messages delivered immediately.

Dave Crocker writes:
> 4. The IETF does not do intranet standards.

I have a mailing list for Internet mail implementors. To subscribe, send
an empty message to imis-subscribe <at> list.cr.yp.to.

Contributors can focus on the needs of their users, without artificially
separating Internet discussions from intranet discussions, SMTP
discussions from POP discussions, etc.

---Dan
Permalink | Reply | 1 comment |
headers
D. J. Bernstein | 3 Jul 2001 01:22
Picon

Re: IANA SMTP registry


http://cr.yp.to/smtp/ehlo.html includes a list of all the extension
names I've seen from SMTP servers.

The goal of the list is to prevent accidental conflicts. That's why ONEX
and VERB and various X* names are listed. I'm not going to limit the
list to IETF projects; that would interfere with the goal.

Let me know if you have any new names.

---Dan
Permalink | Reply | 4 comments |
headers
Keith Moore | 3 Jul 2001 01:49
Picon

Re: SMTP QoS


> I prefer to have all messages delivered immediately.

so would we all.  the only time that a priority mechanism is an issue
is when there are limited resources.
Permalink | Reply | 0 comments |
headers
Dave Crocker | 5 Jul 2001 08:21

Re: SMTP QoS


Howdy,

Having thoroughly overdosed on fireworks, and trying to focus on the 
substantial issues, and being surprised how many there are...

I.      LACK OF SEMANTICS

At 03:07 PM 7/1/2001, ned.freed <at> mrochek.com wrote:
>Now, none of this implies that priority cannot be carried in a header.

         Perhaps the most basic issue is that the specification
         is standardized syntax, without any standardized
         semantics.

         The specification says that each MTA can do whatever it
         feels like with the message.

How can we possibly expect any sort of Internet-wide useful service out of 
this?

-----

II.     LIKELIHOOD OF ABUSE

>>The past experience you have been citing pertains to LOWER priority.  That
>>is quite different from one which includes HIGHER priority.
>
>Only one instance of past experience pertains to LOWER priority. Other
>instances pertain to higher priority, and there has been no indication of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Keith Moore | 6 Jul 2001 18:12
Picon

heads up: IPv6 SMTP operational requirements draft


SMTP folks might want to look at this Internet-Draft:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Next Generation Transition Working Group of the IETF.

        Title           : IPv6 SMTP operational requirements
        Author(s)       : M. Nakamura, J. Hagino
        Filename        : draft-ietf-ngtrans-ipv6-smtp-requirement-01.txt
        Pages           : 6
        Date            : 05-Jul-01

The memo lists operational requirements for IPv6 SMTP, and IPv6-capable
MX DNS records.  As we deploy IPv6 SMTP servers, it became apparent that
we need certain configuration in IPv6-capable MX DNS record, for stable
dual-stack (IPv4 and IPv6) SMTP operations.  The document tries to
clarify the problems we have in transition period between IPv4 SMTP and
IPv6 SMTP, and operational requirements for stable IPv4/v6 SMTP
operation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-ipv6-smtp-requirement-01.txt
Permalink | Reply | 0 comments |
headers
white_snake | 7 Jul 2001 12:22
Favicon

Max. no of allowed "rcpt to" commands in a smtp session?


Hi All,

I couldn't find any information about max no of "rcpt to" commands
allowed in a single smtp session in rfc2821. It looks like there is
no limit defined for it. I don't wanna let any spammer to send
hundereds of mails in a single smtp session.So , what is the resonable
max number of "rcpt to" commands for a single smtp session?

Regards,

__________________________________________________
ÜCRETSÝZ E-MAIL ALDINIZ MI?
Türkçe ilk Portal  http://www.mynet.com
Permalink | Reply | 1 comment |
headers
ned+ietf-smtp | 7 Jul 2001 17:01

Re: Max. no of allowed "rcpt to" commands in a smtp session?


> I couldn't find any information about max no of "rcpt to" commands
> allowed in a single smtp session in rfc2821.

See Section 4.5.3.1. It says:

recipients buffer

       The minimum total number of recipients that must be buffered is 100
       recipients. Rejection of messages (for excessive recipients) with fewer
       than 100 RCPT commands is a violation of this specification. The general
       principle that relaying SMTP servers MUST NOT, and delivery SMTP
       servers SHOULD NOT, perform validation tests on message headers suggests
       that rejecting a message based on the total number of recipients
       shown in header fields is to be discouraged. A server which imposes a
       limit on the number of recipients MUST behave in an orderly fashion,
       such as to reject additional addresses over its limit rather than
       silently discarding addresses previously accepted. A client that needs
       to deliver a message containing over 100 RCPT commands SHOULD be
       prepared to transmit in 100-recipient "chunks" if the server declines to
       accept more than 100 recipients in a single message. 

The wording is quite different but the limit value hasn't changed from RFC 821.

> It looks like there is no limit defined for it.

Nope. See above.

> I don't wanna let any spammer to send
> hundereds of mails in a single smtp session.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane