On May 10, 2017, at 5:16 PM, Sami Ketola sami.ketola@dovecot.fi wrote:
On 10 May 2017, at 16.26, KT Walrus kevin@my.walr.us wrote:
# curl -v -X POST -u doveadm:hellodoveadm -H "Content-Type: application/json" -d '[["save",{"user":"samik","mailbox":"INBOX/myfoldertoo","file":"From: Joulu Pukki joulu.pukki@korvatunturi.fi\nSubject: plaa\n\nmail body\n"},"bb"]]' http://localhost:8080/doveadm/v1
Thanks. I worry that by inlining the entire message in the curl command, the message might exceed some limits on how long a command can be. Some of my messages are up to 20MBs with the attachments and 1MB messages are very common. I also worry about the raw message having unescaped quotes in the message messing up to actual storage of the message in the INBOX. Are HTML mail messages encoded to be safe to enclose in quotations? Or, should I encode the entire mail message and trust that Dovecot can handle decoding the message in the back end?
The question is: why do you want to deliver 20MB messages with doveadm http api? I would not replace LMTP with that.
I could certainly end up using SMTP/LMTP, but in my case I need complete control over when, where, and how messages are delivered. The IMAP interface gives me that control, but the Doveadm HTTP API seems easier and I can do operations that span all users with this API. So, I don’t need to worry as much about scaling (since I think IMAP is limited to one user at a time per connection).
If the Doveadm HTTP API isn’t mature enough or have a PHP interface (like Roundcube gives me for IMAP), I may have to just go with IMAP or SMTP. SMTP is a whole lot easier from PHP of my 3 options, but only handles new message delivery and not the other admin actions I need to do. Eventually, I want to hire some programmers to code my admin app in Go and move to a micro-services architecture, but to start out, when scaling isn’t that important, I’m coding the mail admin app in PHP (since Roundcube Framework gives me a lot of mail handling classes that are mature and well tested).
Kevin