[Dovecot] Saving Sent Messages to Sent Folder
lists at wildgooses.com
Fri Mar 5 13:18:55 EET 2010
On 05/03/2010 10:10, Timo Sirainen wrote:
> On Fri, 2010-03-05 at 09:59 +0000, Ed W wrote:
>>> MUA would have to support both of those URLAUTH and BURL extensions, so
>>> that it can register a temporary URL on the IMAP server, then connect to
>>> SMTP server and give that URL to BURL command (instead of sending the
>>> mail with DATA command).
>>> So from MUA's point of view it's basically the same as before: save to
>>> IMAP and after that send via SMTP.
>> This seems like such a convolution...
>> Given that the RFC already proposes some changes to the IMAP side then
>> it would seem sensible to get the IMAP server to do the proxy connection
>> to the MTA and deliver. Perhaps a simple case of adding a flag when
>> saving into a folder would mark the message as being required to be sent
> Well, I'm not very happy about the idea of IMAP server sending messages
> to SMTP server either.. :)
Go on... Why's that..?
Weight of history defines that we do things in certain ways and we
sometimes get stuck in a bit of a rut, but if M$ has shown us one thing
it's that we should (cautiously) look at how disparate systems can be
integrated into a cohesive whole (granted they also showed how you can
make an insecure system also, but I think that's an optional problem).
Not a dig at Dovecot, but: many software projects overlook the
opportunity to integrate with other systems and become larger than the
individual pieces. An example in point would be that I'm sitting here
battling with SNMP + Cacti + Nagios trying to get them all to talk to
each other... There has to be a reason Groundworks charges so much for
selling you a package where this is already done...
Spinning off at a tangent, but I fell in love with (the concept of)
Lotus Notes some 18 years ago. The way I saw it was a massive
distributed multi-master data store + some presentation layers which
could make any database look like whatever you wanted it to look like.
I used it for:
- Email inbox
- Project documentation, discussion and design
- Staff holiday tracking
- Recruitment workflow (track all candidate details, results of
interviews, contact correspondence, etc)
- Loads of inhouse custom one off projects
I also used it as an SQL database (with a bit of magic) and built an
application used to handle billions of £s of financing for a UK bank.
The IRA blew up one of the banks offices (which kind of stopped the
server working so well), all the staff simply changed their Notes tel
number to that of a different office and just carried on as though
nothing had happened... No data lost, work carried on
I had naively assumed that IMAP servers would head down the same road...
To my eye it's all just unstructured data and I really don't see what's
so special about a CalDev server or an SMTP server which makes it
anything other than a plugin to "an unstructured data store".
If anyone starts to buy that idea then lift your vision and imagine that
we start to see all these just distributed databases, specialist
interfaces to query them efficiently and a bunch of protocols to
distribute documents between the databases - personally I would then
vote we start to shift to some kind of jabber style protocol to connect
all these datastores together. Once you head down that road you can
imagine perhaps an MMS style storage model where the sender hosts all
the mail storage and just sends a short "SMS" note to the recipient to
let them know an email is waiting for them. (possibly even has some
small positive anti-spam benefit...)
Anyway, back to reality...
So what's the problem with a protocol extension which effectively means
"take this message, connect to the server which was pre-configured and
fully tested by you earlier, and give it a "MAIL FROM", "RCPT TO",
"DATA" and let me know the answer"?
More information about the dovecot