On 2010-03-03 Stan Hoeppner wrote: > Ansgar Wiechers put forth on 3/3/2010 9:01 AM: >> I was under the impression that his Postfix and Dovecot are running >> on the same (remote) host, and he's using Postfix as a smarthost for >> his outbound mail. If that's the case, then there certainly is an >> advantage, as his client won't have to transfer the message twice. >> Otherwise you're correct, of course. > > The point I was making is that the BCC'd copy is dropped in his inbox. > Thus, when he opens his MUA, he still has to download the BCC'd sent > items and move them to his IMAP sent items folder. So there's no net > gain in IMAP traffic reduction.
You're kidding, right? You certainly can't mean to imply that *not* having to transfer a large mail over the network via IMAP would be anything else than a significant reduction in IMAP traffic. > I suppose it might be possible to hack together a solution in the MTA > or IMAP server, manually dropping copies of sent messages in the > user's IMAP Sent Items folder. That would be one heck of a kludge > though. Not really. Use submission with a recipient_bcc_maps option and a sender_access map (or something) to add a custom header. Have the MDA store mails with that custom header in the "sent items" folder. Still a bit of a hack, but not as ugly as you make it sound. [...] >>> My Dovecot server is local, 100BaseT, and it's still noticeably >>> faster to store Sent Items locally on the workstation. >> >> Well, duh. Even old PATA/33 drives have almost three times the >> transfer rate of 100BaseT. > > Transfer rate isn't the issue, but latency. Local disk writes are > buffered, whereas network writes via IMAP are not. You're talking nonsense. Of course transfer rate is exactly the issue at hand when we're talking about initially storing a large e-mail in a folder a) on a local disk or b) on a remote IMAP server. Regards Ansgar Wiechers -- "Abstractions save us time working, but they don't save us time learning." --Joel Spolsky
