Eduardo M KALINOWSKI wrote:
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
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
