--On Wednesday, September 5, 2001 10:45 -0400 Ken Murchison
<ken(_at_)oceana(_dot_)com> wrote:
- Is advertising the available options a security problem that we should
avoid?
I don't think so. But you definitely need to document the security
considerations for this extension as a whole.
- Should we restrict the allowable flags chars to a smaller set (ie,
UALPHA, LALPHA, no specials)?
I wouldn't bother.
the server. The syntax of the parameter is as follows, using
the augmented BNF notation of [RFC2822]:
opts-param ::= [1*atext]
Just use "esmtp-value" from RFC 2821. atext includes "=" which is
forbidden in ESMTP values.
If the parameter is omitted no information is conveyed about
the server's supported delivery options;
(4) one optional parameter using the keyword "OPTIONS" is added to
the RCPT TO command. The value associated with this parameter
is a list of single-character delivery options to be used for
the recipient. The syntax of the value is as follows, using
the augmented BNF notation of [RFC2822]:
opts-value ::= 1*81atext
I'd just make it "esmtp-value" and make the length limit a comment.
The following are to be added to the IANA registry for LMTP delivery
options as the initial contents of the registry.
Name: Quota override
Option: q
Name: ACL override
Option: a
These need a lot more description.
What type of registry are you proposing? I'd lean towards the "standards
track or IESG reviewed experimental RFC required" level. These delivery
options need careful review of security considerations section.
- Chris