[Dovecot] Saving Sent Messages to Sent Folder

[Ed W]

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
>> onwards?
>>      
> 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
- Calendar
- 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"?

Cheers

Ed W