[Dovecot] Sending email with IMAP instead of SMTP?
Here's a kind of "outside the box" thought.
Why not extend the IMAP protocol to send email? Instead of having to use SMTP if an addition were made to the IMAP protocol then IMAP could transport outgoing mail to the server the same way it moves messages to the server. On the server end Dovecot would deliver outgoing email to the host MTA via localhost:25.
The advantage would be that clients need not have to deal with a separate configuration for outgoing email. If they have an IMAP connection and already authenticated and perhaps encrypted, then they can transport outgoing mail over the same connection.
Of course - email clients would have to have this feature added as well, but it should be trivial. It could be as easy as moving a message to an "out" box on the server, but the out box really is outgoing email rather than a real imap folder.
Am I the first one to think of this?
Nope, Courier does it
Brent
Quoting Marc Perkel marc@perkel.com:
Here's a kind of "outside the box" thought.
Why not extend the IMAP protocol to send email? Instead of having to use SMTP if an addition were made to the IMAP protocol then IMAP could transport outgoing mail to the server the same way it moves messages to the server. On the server end Dovecot would deliver outgoing email to the host MTA via localhost:25.
The advantage would be that clients need not have to deal with a separate configuration for outgoing email. If they have an IMAP connection and already authenticated and perhaps encrypted, then they can transport outgoing mail over the same connection.
Of course - email clients would have to have this feature added as well, but it should be trivial. It could be as easy as moving a message to an "out" box on the server, but the out box really is outgoing email rather than a real imap folder.
Am I the first one to think of this?
This message was sent using IMP, the Internet Messaging Program.
Is there any client support for this?
On Tue 16 Aug 02005 at 11:48:23AM -0500, bclements@io-networks.com wrote:
Nope, Courier does it
Brent
Quoting Marc Perkel marc@perkel.com:
Here's a kind of "outside the box" thought.
Why not extend the IMAP protocol to send email? Instead of having to use SMTP if an addition were made to the IMAP protocol then IMAP could transport outgoing mail to the server the same way it moves messages to the server. On the server end Dovecot would deliver outgoing email to the host MTA via localhost:25.
The advantage would be that clients need not have to deal with a separate configuration for outgoing email. If they have an IMAP connection and already authenticated and perhaps encrypted, then they can transport outgoing mail over the same connection.
Of course - email clients would have to have this feature added as well, but it should be trivial. It could be as easy as moving a message to an "out" box on the server, but the out box really is outgoing email rather than a real imap folder.
Am I the first one to think of this?
This message was sent using IMP, the Internet Messaging Program.
-- Jacob Elder
Really - how does it work? What email clients talk to it? Is thee a web page that talks about it? Should Dovecot do it too?
bclements@io-networks.com wrote:
Nope, Courier does it
Brent
Quoting Marc Perkel marc@perkel.com:
Here's a kind of "outside the box" thought.
Why not extend the IMAP protocol to send email? Instead of having to use SMTP if an addition were made to the IMAP protocol then IMAP could transport outgoing mail to the server the same way it moves messages to the server. On the server end Dovecot would deliver outgoing email to the host MTA via localhost:25.
The advantage would be that clients need not have to deal with a separate configuration for outgoing email. If they have an IMAP connection and already authenticated and perhaps encrypted, then they can transport outgoing mail over the same connection.
Of course - email clients would have to have this feature added as well, but it should be trivial. It could be as easy as moving a message to an "out" box on the server, but the out box really is outgoing email rather than a real imap folder.
Am I the first one to think of this?
This message was sent using IMP, the Internet Messaging Program.
-- Marc Perkel - marc@perkel.com
Spam Filter: http://www.junkemailfilter.com My Blog: http://marc.perkel.com
Marc Perkel wrote:
Really - how does it work? What email clients talk to it? Is thee a web page that talks about it? Should Dovecot do it too?
http://www.courier-mta.org/imap/smap.html http://www.courier-mta.org/cone/smap1.html http://www.courier-mta.org/cone/index.html
But the world of mail is slowly evolving, esp. with non-urging problems, so this will probably never be widely deployed.
--On Tuesday, August 16, 2005 9:46 AM -0700 Marc Perkel marc@perkel.com wrote:
Why not extend the IMAP protocol to send email?
I recall that qpopper had a POP3 extension that did this.
On Tue, 2005-08-16 at 10:30 -0700, Kenneth Porter wrote:
--On Tuesday, August 16, 2005 9:46 AM -0700 Marc Perkel marc@perkel.com wrote:
Why not extend the IMAP protocol to send email?
I recall that qpopper had a POP3 extension that did this.
Would it really be all that useful though? I can't see it making dovecot 1.0 at least. SMTP is standard for mail relaying for a very good reason.
Regards Andrew
-- Andrew Hutchings (A-Wing) - Linux Guru Netserve Consultants - http://www.domaincity.co.uk/ Linux CDs and DVDs - http://www.linuxiso.co.uk/ Random quote 36: "NT is the path to the darkside...NT leads to Blue Screen. Blue Screen leads to downtime. Downtime leads to suffering...I sense much NT in you." - Unknown Unix Jedi
Courier has this - you can configure an 'outbox' that is polled
i think the contents are either sent to the MTA for smtp , or handled via an internal smtp server
extending either protocol to handle the other is odd though - look at the names of the acronyms
IMAP - internet message access protocol SMTP - simple message transfer protocol
On Aug 16, 2005, at 1:37 PM, Andrew Hutchings wrote:
On Tue, 2005-08-16 at 10:30 -0700, Kenneth Porter wrote:
--On Tuesday, August 16, 2005 9:46 AM -0700 Marc Perkel marc@perkel.com wrote:
Why not extend the IMAP protocol to send email?
I recall that qpopper had a POP3 extension that did this.
Would it really be all that useful though? I can't see it making dovecot 1.0 at least. SMTP is standard for mail relaying for a very good reason.
Regards Andrew
Ever send a large attachment over a slow connection with an IMAP mail store? The message has to be sent twice, first via SMTP then to your Sent Messages folder. I've thought about writing a Postfix policy daemon to support this a different way, much like GMail's POP3/SMTP support.
On Tue 16 Aug 02005 at 06:37:33PM +0100, Andrew Hutchings wrote:
On Tue, 2005-08-16 at 10:30 -0700, Kenneth Porter wrote:
--On Tuesday, August 16, 2005 9:46 AM -0700 Marc Perkel marc@perkel.com wrote:
Why not extend the IMAP protocol to send email?
I recall that qpopper had a POP3 extension that did this.
Would it really be all that useful though? I can't see it making dovecot 1.0 at least. SMTP is standard for mail relaying for a very good reason.
Regards Andrew
-- Andrew Hutchings (A-Wing) - Linux Guru Netserve Consultants - http://www.domaincity.co.uk/ Linux CDs and DVDs - http://www.linuxiso.co.uk/ Random quote 36: "NT is the path to the darkside...NT leads to Blue Screen. Blue Screen leads to downtime. Downtime leads to suffering...I sense much NT in you." - Unknown Unix Jedi
-- Jacob Elder
On 16.8.2005, at 20:43, Jacob Elder wrote:
Ever send a large attachment over a slow connection with an IMAP mail store? The message has to be sent twice, first via SMTP then to your Sent Messages folder. I've thought about writing a Postfix policy daemon to support this a different way, much like GMail's POP3/SMTP support.
Lemonade IETF group is designing some kind of "submit protocol" which would allow this. I haven't been following them for months though, so I don't know their current status.
On Tue, 2005-08-16 at 13:43 -0400, Jacob Elder wrote:
Ever send a large attachment over a slow connection with an IMAP mail store? The message has to be sent twice, first via SMTP then to your Sent Messages folder. I've thought about writing a Postfix policy daemon to support this a different way, much like GMail's POP3/SMTP support.
Hmm...makes sense I guess, but I can't see it being easy to explain to my customers (it was hard enough explaining what IMAP was ;) Again it does depend on client support, most clients demand an SMTP connection to send, and dumping a draft in an outbox just doesn't seem right somehow. There may be also a risk of duplicates and such which need to be considered. I think this is more a dovecot 1.1 or 2 feature still.
Regards Andrew
Andrew Hutchings (A-Wing) - Linux Guru Netserve Consultants - http://www.domaincity.co.uk/ Linux CDs and DVDs - http://www.linuxiso.co.uk/ Random quote 47: "The best way to accelerate a computer running Windows is at 9.81 m/s²." - Anon.
Jacob Elder wrote:
Ever send a large attachment over a slow connection with an IMAP mail store?
Not so bad since I stopped copying mails to Sent, but BCC a special email-address, so the mail gets delivered to my Sent folder on the server. Of course, my MUA needs to download the mail, but that's ok with ADSL and I usually delete the BCC (which I told Thunderbird to insert by default) with large messages.
Andrew Hutchings wrote:
On Tue, 2005-08-16 at 10:30 -0700, Kenneth Porter wrote:
Would it really be all that useful though? I can't see it making dovecot 1.0 at least. SMTP is standard for mail relaying for a very good reason.
This is all just theoretical. The idea isn't to eliminate SMTP. Servers would still talk SMTP to each other. The advantage is that when you configure a client you would only have to configure the IMAP. It wouldn't require an additional step for setting up outgoing email. And on the server end you wouldn't have to set up SMTP authentication because the IMAP would already do that for you. IMAP would act as a transport to get the outgoing mail from the client to the SMTP server.
On 2005-08-16 13:43:46 -0400 Marc Perkel marc@perkel.com wrote:
Andrew Hutchings wrote:
On Tue, 2005-08-16 at 10:30 -0700, Kenneth Porter wrote:
Would it really be all that useful though? I can't see it making dovecot 1.0 at least. SMTP is standard for mail relaying for a very good reason.
This is all just theoretical. The idea isn't to eliminate SMTP. Servers would still talk SMTP to each other. The advantage is that when you configure a client you would only have to configure the IMAP. It wouldn't require an additional step for setting up outgoing email. And on the server end you wouldn't have to set up SMTP authentication because the IMAP would already do that for you. IMAP would act as a transport to get the outgoing mail from the client to the SMTP server.
So, just a particular IMAP mailbox, then? And what would happen if you copied a random received email into that box? Say, one to the dovecot mailing list?
How do you do blind carbon copy? Despite the pseudo-header displayed by mail clients (and typically saved as a Bcc: header in a sent-mail box, if your MUA is configured to store sent mails), this is not supplied to the outgoing SMTP server as a header.
Or, in other words, how much header munging does the IMAP-send-enabled MUA
do, and how much is left to the IMAP-send-enabled imapd? If imapd sets SMTP
MAIL FROM:, does it also munge From:? Sender:? Resent-From:? List-From:?
X-Secret-Message-From:?
Not saying that these issues can't be resolved, just that they do exist, and consequently MUST be resolved; depending on how much complexity implementation requires of the server versus the MUA, you'll see different implementation results.
The two use cases suggested seem to be: reduce transmission time for sending/storing as sent-mail; reduce configuration complexity. For reduction of configuration complexity, it will depend on support for the capability in clients commonly used by less technical users. Reduction of transmission time alone seems marginal as a use case, given possible complexities and interoperability issues.
Amy!
Amelia A. Lewis amyzing {at} talsever.com The less I seek my source for some definitive, the closer I am to fine. -- Indigo Girls
All this discussion is being done already....
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-maes-lemonade-deliver-00.txt
There are past I-Ds regarding other approaches to submission, but this appears to be the current proposal on the table. This draft makes a lot of references to the "Lemonade Profile" (aka "P-IMAP", simplification extensions for IMAP, another Internet-Draft), but the LDELIVER extension can be implemented on its own outside of the P-IMAP context.
-- -- Todd Vierling tv@duh.org tv@pobox.com todd@vierling.name
All this discussion is being done already....
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-maes-lemonade-deliver-00.txt
There are past I-Ds regarding other approaches to submission, but this appears to be the current proposal on the table.
LDELIVER is best ignored, the solution which has broad support and shortly will be submitted for final approval by the IESG is a trio of standards:
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-catenate-05.txt http://www.ietf.org/internet-drafts/draft-ietf-lemonade-urlauth-07.txt http://www.ietf.org/internet-drafts/draft-ietf-lemonade-burl-02.txt
this allows IMAP to be IMAP and SMTP to be SMTP. you still need to access an SMTP server directly (which I consider a feature), but you don't have to download or upload any data yourself, the SMTP server will fetch it for you.
see also: http://www.ietf.org/html.charters/lemonade-charter.html http://flyingfox.snowshore.com/i-d/lemonade/
Kjetil T.
Amelia A Lewis wrote:
Or, in other words, how much header munging does the IMAP-send-enabled MUA do, and how much is left to the IMAP-send-enabled imapd? If imapd sets SMTP MAIL FROM:, does it also munge From:? Sender:?
Resent-From:? List-From:? X-Secret-Message-From:?
It only munges BCC: by deleting it. Standard sendmail does the same when you call it with -t and provide a message on the standard input.
The "IMAP Outbox" feature has been around for quite a while. You don't need to change Dovecot to implement it. Given maildir storage, just scan users "Outbox" folders and pipe any message found there to "sendmail -t", then move it to the "Sent" folder on success.
Here's the relevant part of the exim documentation (which is feature compatible to sendmail on the command line):
-t
When Exim is receiving a locally-generated, non-SMTP message on its standard input, the -t option causes the recipients of the message to be obtained from the To:, Cc:, and Bcc: header lines in the message instead of from the command arguments. The addresses are extracted before any rewriting takes place.
If the command has any arguments, they specify addresses to which the message is not to be delivered. That is, the argument addresses are removed from the recipients list obtained from the headers. This is compatible with Smail 3 and in accordance with the documented behaviour of several versions of Sendmail, as described in man pages on a number of operating systems (e.g. Solaris 8, IRIX 6.5, HP-UX 11). However, some versions of Sendmail add argument addresses to those obtained from the headers, and the O'Reilly Sendmail book documents it that way. Exim can be made to add argument addresses instead of subtracting them by setting the option extract_addresses_remove_arguments false.
If a Bcc: header line is present, it is removed from the message unless there is no To: or Cc:, in which case a Bcc: line with no data is created. This is necessary for conformity with the original RFC 822 standard; the requirement has been removed in RFC 2822, but that is still very new.
If there are any Resent- header lines in the message, Exim extracts recipients from all Resent-To:, Resent-Cc:, and Resent-Bcc: header lines instead of from To:, Cc:, and Bcc:. This is for compatibility with Sendmail and other MTAs. (Prior to release 4.20, Exim gave an error if -t was used in conjunction with Resent- header lines.)
RFC 2822 talks about different sets of Resent- header lines (for when a message is resent several times). The RFC also specifies that they should be added at the front of the message, and separated by Received: lines. It is not at all clear how -t should operate in the present of multiple sets, nor indeed exactly what constitutes a “set”. In practice, it seems that MUAs do not follow the RFC. The Resent- lines are often added at the end of the header, and if a message is resent more than once, it is common for the original set of Resent- headers to be renamed as X-Resent- when a new set is added. This removes any possible ambiguity.
/tom
participants (12)
-
Amelia A Lewis
-
Andrew Hutchings
-
bclements＠io-networks.com
-
Jacob Elder
-
Jakob Hirsch
-
Jonathan Vanasco
-
Kenneth Porter
-
Kjetil Torgrim Homme
-
Marc Perkel
-
Timo Sirainen
-
Todd Vierling
-
Tom Kistner