At 9:01 PM -0800 3/28/97, Chris Newman wrote:
The proper place for the MTA filtering language is the same protocol
that's used to configure the MTA.
But MTAs often don't have configuration protocols, and when they do they
are likely to be non-standard. So how is a mail client to know what
filtering is available?
The proper place to advertise MTA supported filtering extensions should
also be the same protocol that's used to configure the MTA. I think IMAP
is the wrong place to advertise this because the only place where IMAP
currently has to interface to the final-delivery agent is the mailstore.
If the mailstore is a legacy mailstore, it's quite likely the IMAP server
and final delivery agents will be from different vendors and will know
very little about each other.
It seems to me that the final delivery agent, whatever it is, can always
get a user's filters from ACAP (or even a more efficient non-standard
back-end as an option). But this still leaves the problem of how to
advertise to the client that final dilvery filtering is available, and what
extensions are supported.
I can think of four choices:
1. Advertise it in ESMTP (EHLO response).
2. Advertise it in Submit protocol
3. Advertise it in an ACAP CAPABILITY
4. Have an ACAP dataset for "local facilities" which includes an "MTA
Filtering" attribute. This would be read-only for clients.
I really hate #1. I could live with #2, but I think these are different
actions, likely to be done by different servers. #3 makes some sense to
me, but I understand your objections. #4 would work, especially since ACAP
is the means of communicating filters from client to server.