Chris Newman wrote:
--On Thursday, August 30, 2001 17:42 -0400 Ken Murchison
I *think* Larry and I had discussed somthing like this before
implementing IGNOREQUOTA. Are you proposing something like an
extensible FLAGS keyword, ie:
RCPT TO:<foo(_at_)example(_dot_)com> FLAGS=qa
q = no quota check
a = no acl check
I figure that using single-letter flags would be better than keywords,
since it would keep the max length of the RCPT command down to a
Yes, I like the FLAGS proposal better. We might want to have the LMTP
server ignore unknown letters to make it simpler to extend later.
Right. I was thinking the same thing.
Should we limit the flags in any way (ie alpha-numeric, uppercase-only)
or allow any printable char?
Should we setup a registry at IANA for the flags?
If I write up a draft, should it document just the flags mechanisms, or
should it also mention the 'q' and 'a' flags?
Another extension I've been thinking of along these lines is one to pass
attribute-value pairs from LDAP. Contemplate this scenario:
->| LDAP |<-
/ +--------+ \
incoming mail ---> | SMTP relay for site |---LMTP----->| mailstore |
Now since the SMTP relay has to do an LDAP lookup for each recipient to
find the right backend mailstore, wouldn't it be cool if the SMTP relay
also passed along all the LDAP attributes the mailstore needed so the
mailstore didn't have to look up the recipient in LDAP again?
Seems like saving one network round trip per recipient in this scenario
might be worth the extra complexity needed to pass freeform LDAP-style
attribute value-list pairs.
So perhaps something like:
Interesting, but since neither I nor Cyrus IMAP need this right now,
I'll defer to you on this one. Unless you think that these "deliver
options" mechanisms belong in the same draft.
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26 Orchard Park, NY 14127
--PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp