Daniel L. Miller escreveu:
So, without changing the MUA/MTA/IMAP interaction, the IMAP server will simply file new messages according to user-set rules. Doesn't address the multiple-transfer issue at all, but does provide an option for centralized control of message filing.
With the APPEND command, storing the mail somewhere that is not the default location would be a violation of the protocol:
6.3.11. APPEND Command
Arguments: mailbox name OPTIONAL flag parenthesized list OPTIONAL date/time string message literal
Responses: no specific responses for this command
Result: OK - append completed NO - append error: can't append to that mailbox, error in flags or date/time or message text BAD - command unknown or arguments invalid
The APPEND command appends the literal argument as a new message to the end of the specified destination mailbox. This argument SHOULD be in the format of an [RFC-2822<http://www.faqs.org/rfcs/rfc2822.html>] message.
The simplest solution would be, as already mentioned, configure the client to BCC yourself, and filter that message. (And disable the 'Store copy of sent mails' option.) I do not think running filters for APPEND'ed messages is an option (even if one not active by default). First - I can't argue the point about BCC'ing - you're certainly correct
Eduardo M KALINOWSKI wrote:
that that would be the "simplest" solution in terms of immediate
implementation - if we assume users are willing to change their habits.
Since I don't - I'm exploring server-side options
I disagree about "violating" the protocol. Nothing about the mail server/client communication would change - the client would still receive an "OK" at the end. The difference would be after the message appeared in the "Sent" folder (or never show at all), a moment later it would disappear and be placed in the sieve-directed folder. I don't see how this violates the protocol - though I do agree it would be quite confusing for someone who wasn't aware of this behavior.
Daniel