Re: objections, again

[Ned Freed <[e-mail]>]

> Under RFC 2119, section 6,

>    Imperatives of the type defined in this memo must be used with care
>    and sparingly.  In particular, they MUST only be used where it is
>    actually required for interoperation or to limit behavior which has
>    potential for causing harm (e.g., limiting retransmisssions)  For
>    example, they must not be used to try to impose a particular method
>    on implementors where the method is not required for
>    interoperability.

> I run a mail server that accepts mail for duh.org.  YOU HAVE NO AUTHORITY to
> control how mail is handled once it enters my system, or the validity or
> equality of addresses before the @.  THAT IS MY MTA'S CHOICE, not yours. B
> Not even a 'VRFY' or 'EXPN' SMTP command gives any kind of assurance on
> deliverability or identity of addressing.  Only an actual attempt at mail
> delivery does.

On the contrary, the IETF has had standards in place for a long time that
impose mandatory requirements on the namespace to the left of the @. In fact
not only is this done, one case where it is done is at full standard status.

I'm referring, of course, to the mandate in RFC1123 that any host that supports
a receiver-SMTP also support a mailbox called "postmaster". And there's also a
requirement that "postmaster" be supported in a case-insensitive fashion (a
pain to implement, BTW, and the source of at least one round of standards
incompliancy in sendmail).

And this isn't the only example of such a specification. There's also RFC2142,
now a proposed standard, which mandates a wide variety of mailbox names for
hosts offering various classes of service.

Now, you use the term "authority" above. And in this sense you're absolutely
right, the IETF doesn't have any authority to force you to comply with IETF
standards. You are completely free to comply with none, some, or all IETF
standards. You don't have to have a "postmaster" mailbox on your system (and in
fact an unfortunately large number of systems don't), in which case you aren't
in compliance with RFC1123. Or you can implement subaddressing in an entirely
different way than what a standards-track specifaction says, in which case you
woult not be in compliance with it.

But all this means is that you are not in compliance. Nobody is going to arrest
you for either action. You may get in trouble with someone somewhere because
they expected you to conform to some set of IETF standards but you did not, of
course. However, such contractural arrangements are outside the scope of the
IETF.

But this doesn't mean we cannot write standards that impose certain syntactic
and semantic requirements on what appears to the left of the @ in an email
address. We can. We have done so in the past and I'm sure we'll do so again in
the future.

In fact not only have we imposed such requirements in the past, we've done
something worse -- we have in fact let prose slip into standards-track
specifications that says certain mailbox name forms be interpreted in
particular ways even when they appear in conjunction with a domain that isn't
your own! This last is hard to believe I know, but you'll find that RFC1327 can
be read this way. Note that RFC1327 will soon be replaced with MIXER, where I
believe the problem to be corrected.)

Please note that I'm not commenting on the subaddress proposal either pro
or con. I'm only addressing the procedural issue of whether or not such
a proposal is in scope for the IETF to produce.

				Ned