[Dovecot] Sending email over IMAP?
I'm advocating for a change in the IMAP specification to allow outgoing email to be sent over the same connection as incoming rather that having to separately configure outgoing SMTP email. There are two significant advantages to this concept.
It would greatly simplify setup for clients as they would only have to configure one connection rather than two.
Spam reduction by authentication. The sending of email over the same connection tells the server that the person who is the sender of the email also has demonstrated they have access to read the account. This would be a powerful whitelisting criteria for eliminating fake senders.
So - my question. It seems that it would be easy to do this if there were a standard. Dovecot would merely hand incoming email off to the outgoing SMTP server. Besides the difficulty of getting a standard created, am I right on my assumptions?
Marc Perkel wrote:
- Spam reduction by authentication. The sending of email over the same connection tells the server that the person who is the sender of the email also has demonstrated they have access to read the account. This would be a powerful whitelisting criteria for eliminating fake senders.
That wouldn't work. What would be the next SMTP server on the way expected to do? Trust that address authenticity as well?
So - my question. It seems that it would be easy to do this if there were a standard. Dovecot would merely hand incoming email off to the outgoing SMTP server. Besides the difficulty of getting a standard created, am I right on my assumptions?
Getting such standard adopted by clients, I'd say :)
Cheers, -jkt
-- cd /local/pub && more beer > /dev/mouth
On Thu, 2006-05-04 at 11:05, Marc Perkel wrote:
I'm advocating for a change in the IMAP specification to allow outgoing email to be sent over the same connection as incoming rather that having to separately configure outgoing SMTP email. There are two significant advantages to this concept.
- It would greatly simplify setup for clients as they would only have to configure one connection rather than two.
Why would it be easier for a client to add a new sending method than to simply have an option to use the same credentials for smtp auth for sending.
- Spam reduction by authentication. The sending of email over the same connection tells the server that the person who is the sender of the email also has demonstrated they have access to read the account. This would be a powerful whitelisting criteria for eliminating fake senders.
Smtp auth already handles this.
So - my question. It seems that it would be easy to do this if there were a standard. Dovecot would merely hand incoming email off to the outgoing SMTP server. Besides the difficulty of getting a standard created, am I right on my assumptions?
Most current MUA's already handle smtp authentication and ssl. Why make things worse with yet another standard?
-- Les Mikesell lesmikesell@gmail.com
Les Mikesell wrote:
On Thu, 2006-05-04 at 11:05, Marc Perkel wrote:
I'm advocating for a change in the IMAP specification to allow outgoing email to be sent over the same connection as incoming rather that having to separately configure outgoing SMTP email. There are two significant advantages to this concept.
- It would greatly simplify setup for clients as they would only have to configure one connection rather than two.
Why would it be easier for a client to add a new sending method than to simply have an option to use the same credentials for smtp auth for sending.
But - if it were part of IMAP then half of the setup goes away. Outgoing email configuration goes away.
- Spam reduction by authentication. The sending of email over the same connection tells the server that the person who is the sender of the email also has demonstrated they have access to read the account. This would be a powerful whitelisting criteria for eliminating fake senders.
Smtp auth already handles this.
But - the incoming server and outgoing server can be and usually are different. I can send email spoofing anyone. But if I send through IMAP I would be showing the server that the person sending the email has access to read the email. This would be powerful as an authentication mechanism. With authenticated SMTP all you are says to the world is that you have some account somewhere that will accept your email, but not that you can read it. See the difference?
So - my question. It seems that it would be easy to do this if there were a standard. Dovecot would merely hand incoming email off to the outgoing SMTP server. Besides the difficulty of getting a standard created, am I right on my assumptions?
Most current MUA's already handle smtp authentication and ssl. Why make things worse with yet another standard?
Not making things worse with another standard, just convenient and it has the ability to demonstrate that the email came for the connection that read the email. Is simplification and identity verification.
Marc Perkel wrote:
But - if it were part of IMAP then half of the setup goes away. Outgoing email configuration goes away.
There isn't a single e-mail *client* that would support this anytime soon, even it Timo added tomorrow. That is the #1 reason this won't fly.
You seem to think that "All in one" beats "do one thing and do it well" and pretty much the entire history of the Internet is against you.
Sorry...
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Quoting Marc Perkel <marc@perkel.com>:
But - if it were part of IMAP then half of the setup goes away. Outgoing email configuration goes away.
Only for those who have new clients and servers implementing the new standard (those will old need to do it the old way). And even then, only for those who send their e-mail through the same machine as they read it. And then, only if they only use one email address and not multiple email addresses...
Smtp auth already handles this.
But - the incoming server and outgoing server can be and usually are different.
That is irrelevent.
I can send email spoofing anyone. But if I send through IMAP I would be showing the server that the person sending the email has access to read the email.
SMTP Auth can show this exact same thing, but in neither case does it stop spoofing.
This would be powerful as an authentication mechanism.
No more powerful than SMTP Auth where it uses the same credentials as IMAP.
With authenticated SMTP all you are says to the world is that you have some account somewhere that will accept your email, but not that you can read it. See the difference?
SMTP Auth can be configured exactly as you want. And even so, it doesn't stop spoofing.
Not making things worse with another standard, just convenient and it has the ability to demonstrate that the email came for the connection that read the email. Is simplification and identity verification.
No. It does not in any way stop spoofing just by authenticating. You would need much more to do that. And if you want to do that, why not just add that to the SMTP Auth standards?
-- Eric Rostetter The Department of Physics The University of Texas at Austin
Go Longhorns!
I thought there was already a standard for this, an Outbox folder, similar to a drafts folder except the email is sent. Courier (see http://www.inter7.com/courierimap/INSTALL.html) supports this now (except does not delete from Outbox folder after sending). However, not supported by clients.
It's good because can have IMAP outside the firewall and sending within the firewall. Also, much faster in my experience.
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Thu, 2006-05-04 at 11:24, Marc Perkel wrote:
- It would greatly simplify setup for clients as they would only have to configure one connection rather than two.
Why would it be easier for a client to add a new sending method than to simply have an option to use the same credentials for smtp auth for sending.
But - if it were part of IMAP then half of the setup goes away. Outgoing email configuration goes away.
No it doesn't. The other options are going to go away even if this becomes another choice.
- Spam reduction by authentication. The sending of email over the same connection tells the server that the person who is the sender of the email also has demonstrated they have access to read the account. This would be a powerful whitelisting criteria for eliminating fake senders.
Smtp auth already handles this.
But - the incoming server and outgoing server can be and usually are different. I can send email spoofing anyone.
Again, adding another option doesn't change your ability to spoof through an existing smtp server that allows it. But smtp servers don't have to allow it now.
But if I send through IMAP I would be showing the server that the person sending the email has access to read the email.
What you are showing is that you know some user's password. The same thing you show in smtp auth.
This would be powerful as an authentication mechanism. With authenticated SMTP all you are says to the world is that you have some account somewhere that will accept your email, but not that you can read it. See the difference?
No, in many/most cases it is the same server or at least authenticating against the same login/password database.
Most current MUA's already handle smtp authentication and ssl. Why make things worse with yet another standard?
Not making things worse with another standard, just convenient and it has the ability to demonstrate that the email came for the connection that read the email.
It does make things worse because no client knows how to do it and there would be years of version confusion about which ones do/don't support it if it is added now.
Is simplification and identity verification.
It might have been if it had been done before smtp auth.
-- Les Mikesell lesmikesell@gmail.com
Quoting Marc Perkel <marc@perkel.com>:
I'm advocating for a change in the IMAP specification to allow outgoing email to be sent over the same connection as incoming rather that having to separately configure outgoing SMTP email. There are two significant advantages to this concept.
And at least as many significant disadvantages.
- It would greatly simplify setup for clients as they would only have to configure one connection rather than two.
This is only true if they want to send via the same mechanism they receive from.
- Spam reduction by authentication. The sending of email over the same connection tells the server that the person who is the sender of the email also has demonstrated they have access to read the account. This would be a powerful whitelisting criteria for eliminating fake senders.
Most all MTA systems already allow authentication, so this buys you nothing.
So - my question. It seems that it would be easy to do this if there were a standard. Dovecot would merely hand incoming email off to the outgoing SMTP server. Besides the difficulty of getting a standard created, am I right on my assumptions?
I don't think it matters if it is easy or difficult to do, either in general or for any particular IMAP software. But it does matter that there is a standard. And a way to fall back in the client for those systems which pre-date the new standard.
-- Eric Rostetter The Department of Physics The University of Texas at Austin
Go Longhorns!
Eric Rostetter wrote:
Quoting Marc Perkel <marc@perkel.com>:
I'm advocating for a change in the IMAP specification to allow outgoing email to be sent over the same connection as incoming rather that having to separately configure outgoing SMTP email. There are two significant advantages to this concept.
And at least as many significant disadvantages. Such as?
- It would greatly simplify setup for clients as they would only have to configure one connection rather than two.
This is only true if they want to send via the same mechanism they receive from. Yes - and why wouldn't they want the simplification?
- Spam reduction by authentication. The sending of email over the same connection tells the server that the person who is the sender of the email also has demonstrated they have access to read the account. This would be a powerful whitelisting criteria for eliminating fake senders.
Most all MTA systems already allow authentication, so this buys you nothing. But it's a separate authentication. You can authenticate as anyone or you can find an unauthenticated server that serves that IP space. What I'm proposing ties the sending to the account of the receive showing the server that the same person who can read the email is sending the email.
I can spoof Bill Gates email address and send it. But I can't do that with this protocol.
So - my question. It seems that it would be easy to do this if there were a standard. Dovecot would merely hand incoming email off to the outgoing SMTP server. Besides the difficulty of getting a standard created, am I right on my assumptions?
I don't think it matters if it is easy or difficult to do, either in general or for any particular IMAP software. But it does matter that there is a standard. And a way to fall back in the client for those systems which pre-date the new standard.
I'm not suggesting that we eliminate the old standard but add another choice.
Quoting Marc Perkel <marc@perkel.com>:
And at least as many significant disadvantages. Such as?
See the list discussion for starters...
Most all MTA systems already allow authentication, so this buys you nothing. But it's a separate authentication.
No, it _CAN_ be a authenticate the same credentials, or different ones. As long as the policy is to authenticate the same credentials, then it is the same as your proposal. Your proposal simply limits the options already available, in a way that will probably upset people.
You can authenticate as anyone or
Only if you know their credentials.
you can find an unauthenticated server that serves that IP space.
You can do this with your service also. Just because you say IMAP can now send mail, doesn't mean I have to send my mail that way.
What I'm proposing ties the sending to the account of the receive showing the server that the same person who can read the email is sending the email.
What you are proposing is what I currently implement with SMTP AUTH, but over a single connection instead of two. That's all.
Now, if you also define that this service would force a pre-set email address on the mail sent (which you didn't mention, and which could also be worked into most existing MTA's) _then_ you would move slightly towards reducing spoofing (though not completely, as there are other types of spoofing that the usual types).
I can spoof Bill Gates email address and send it. But I can't do that with this protocol.
You didn't specify that. You would need to define how this would work. I would guess it would work very poorly...
For example, rostetter@mail.utexas.edu is just an alias that doesn't really exists as an account. It is a forwarding alias that resolves to my real account. If you restricted me to only using my real address, I'll not be able to post to the mailing list anymore since my posting address won't match the subscribed address... In other words, your system will/could break mail usage for anyone who uses multiple aliases, multiple addresses, multiple hosts names for the same machine, etc.
I don't think it matters if it is easy or difficult to do, either in general or for any particular IMAP software. But it does matter that there is a standard. And a way to fall back in the client for those systems which pre-date the new standard.
I'm not suggesting that we eliminate the old standard but add another choice.
Just realize that in doing so, you don't get full advantage of your desire for simplification in the setup process.
-- Eric Rostetter The Department of Physics The University of Texas at Austin
Go Longhorns!
Marc Perkel wrote:
I can spoof Bill Gates email address and send it. But I can't do that with this protocol.
You haven't answered my question I asked in the first response in this thread. Your proposal specify that the first server on the way would know if you're allowed to send email for one particular account (that won't work anyway, think about the aliases etc, there's really no way to know "what e-mail addresses is this guy allowed to receive" for an IMAP server). What about other servers throught them the message will have to travel?
Cheers, -jkt
-- cd /local/pub && more beer > /dev/mouth
Jan Kundrát wrote:
Marc Perkel wrote:
I can spoof Bill Gates email address and send it. But I can't do that with this protocol.
You haven't answered my question I asked in the first response in this thread. Your proposal specify that the first server on the way would know if you're allowed to send email for one particular account (that won't work anyway, think about the aliases etc, there's really no way to know "what e-mail addresses is this guy allowed to receive" for an IMAP server). What about other servers throught them the message will have to travel?
Cheers, -jkt
What I'm picturing, and I haven't figured out all the details, is that the IMAP server would also have an SMTP server associated with it and that the IMAP would hand outgoing email to the SMTP server. And that the SMTP server would have the alias information for that user account so it would be able to determine that the email address is real or a configured alias for that account. You do raise a good point.
I'm also am thinking about senders like Paypal and banks who are often spoofed. If the limited all their outbound email to sending over IMAP then they might be able to create a more secure sytem and because of their restrictiveness be able to somehow create a less spoofable more identifyable system.
I think the main advantage here isn't for people like us but for companies who are trying to avoid fraud. I think there will be other side benifits to it as well that will be discovered once it becomes popular. So - I'm thinking that the convience factor, the ease of setup being the initial reason to do it and that once it's in place that other things will be discovered.
I don't have all the answers, but my gut tells me this is a good idea.
On Friday, May 05, 2006 8:42 AM -0700 Marc Perkel <marc@perkel.com> wrote:
I'm also am thinking about senders like Paypal and banks who are often spoofed. If the limited all their outbound email to sending over IMAP then they might be able to create a more secure sytem and because of their restrictiveness be able to somehow create a less spoofable more identifyable system.
MTA's can check SPF records when accepting mail and add headers to indicate whether the sending MTA has valid SPF. For example, sendmail together with a suitable milter (I use MIMEDefang and Spamassassin) can do this. Your MUA then needs to check the result and present it as evidence of spoofing.
Kenneth Porter wrote:
On Friday, May 05, 2006 8:42 AM -0700 Marc Perkel <marc@perkel.com> wrote:
I'm also am thinking about senders like Paypal and banks who are often spoofed. If the limited all their outbound email to sending over IMAP then they might be able to create a more secure sytem and because of their restrictiveness be able to somehow create a less spoofable more identifyable system.
MTA's can check SPF records when accepting mail and add headers to indicate whether the sending MTA has valid SPF. For example, sendmail together with a suitable milter (I use MIMEDefang and Spamassassin) can do this. Your MUA then needs to check the result and present it as evidence of spoofing.
SPF breaks email forwarding.
On Friday, May 05, 2006 3:45 PM -0700 Marc Perkel <marc@perkel.com> wrote:
SPF breaks email forwarding.
While SPF is not a panacea, it does improve spoof detection.
An even better guarantee is a digital signature.
Sending over IMAP doesn't provide any anti-spoofing assurance that authenticated SMTP doesn't already provide.
Kenneth Porter wrote:
On Friday, May 05, 2006 3:45 PM -0700 Marc Perkel <marc@perkel.com> wrote:
SPF breaks email forwarding.
While SPF is not a panacea, it does improve spoof detection.
An even better guarantee is a digital signature.
Sending over IMAP doesn't provide any anti-spoofing assurance that authenticated SMTP doesn't already provide.
But SPF breaks email forwarding. That's not something that I can live with.
On Fri, 2006-05-05 at 16:34 -0700, Marc Perkel wrote:
Kenneth Porter wrote:
On Friday, May 05, 2006 3:45 PM -0700 Marc Perkel <marc@perkel.com> wrote:
SPF breaks email forwarding.
While SPF is not a panacea, it does improve spoof detection.
An even better guarantee is a digital signature.
Sending over IMAP doesn't provide any anti-spoofing assurance that authenticated SMTP doesn't already provide.
But SPF breaks email forwarding. That's not something that I can live with.
Isn't that why SRS exists?
-- Karl Latiss <karl.latiss@atvert.com.au> Atvert Systems
Marc Perkel wrote:
What I'm picturing, and I haven't figured out all the details, is that the IMAP server would also have an SMTP server associated with it and that the IMAP would hand outgoing email to the SMTP server. And that the SMTP server would have the alias information for that user account so it would be able to determine that the email address is real or a configured alias for that account. You do raise a good point.
I'm also am thinking about senders like Paypal and banks who are often spoofed. If the limited all their outbound email to sending over IMAP then they might be able to create a more secure sytem and because of their restrictiveness be able to somehow create a less spoofable more identifyable system.
Nope. They might use any method for their unbound mail, but as long as it goes to jkt@gentoo.org, the SMTP server of Gentoo will be responsible for final delivery to my account. It really can't take any stuff like "sent via IMAP" into consideration as those flags might be easily forged. The only attempt it can do is to check if the mail server that submitted the message in question is actually listed in the sender's domain's DNS information / DomainKey-Signature header. As a result, I wouldn't be able to receive this message as it was forwarded by talvi.dovecot.org...
I think the main advantage here isn't for people like us but for companies who are trying to avoid fraud. I think there will be other side benifits to it as well that will be discovered once it becomes popular.
Can't see any of them :)
So - I'm thinking that the convience factor, the ease of setup being the initial reason to do it and that once it's in place that other things will be discovered.
Ease of setup? Why? If you're a large company, you surely deploy preinstalled computers to your users. It really doesn't matter if you add one more item to the disk image.
Cheers, -jkt
-- cd /local/pub && more beer > /dev/mouth
Marc Perkel wrote:
I'm advocating for a change in the IMAP specification to allow outgoing
Not as bad as your usual ideas, but it has been thought before:
http://www.courier-mta.org/imap/smap.html
I doubt that something like this will spread in the foreseeable future.
Jakob Hirsch wrote:
Marc Perkel wrote:
I'm advocating for a change in the IMAP specification to allow outgoing
Not as bad as your usual ideas, but it has been thought before:
http://www.courier-mta.org/imap/smap.html
I doubt that something like this will spread in the foreseeable future.
You are referring to this?
* SMAP allows a single transaction to save a new message in the
"Sent" folder, and mail it to its designated recipients. IMAP
clients need to transmit the message a second time, using SMTP,
requiring twice as much bandwidth and time as SMAP to do the same
thing.I'd really like to see something like this happen. Wonder what it would take for Dovecot to implement some protocol experimentally to do something like this?
Quoting Marc Perkel <marc@perkel.com>:
- SMAP allows a single transaction to save a new message in the "Sent" folder, and mail it to its designated recipients. IMAP clients need to transmit the message a second time, using SMTP, requiring twice as much bandwidth and time as SMAP to do the same thing.
This would save bandwidth _if_ you use a remote sent-mail folder. Other than that, I see no reason/advantage for it...
At best, it introduces problems like handling the case where one operation (sending it) works but the other (saving it to sent-mail) fails. How do you resolve that?
-- Eric Rostetter The Department of Physics The University of Texas at Austin
Go Longhorns!
On Thursday, May 04, 2006 11:46 AM -0500 Eric Rostetter <rostetter@mail.utexas.edu> wrote:
This would save bandwidth _if_ you use a remote sent-mail folder. Other than that, I see no reason/advantage for it...
A remote sent folder is an important advantage of using IMAP over POP3. It allows most of one's persistent state to be accessible from any client. (LDAP does the same for the address book.)
At best, it introduces problems like handling the case where one operation (sending it) works but the other (saving it to sent-mail) fails. How do you resolve that?
If one uses a remote sent folder, these two operations are one.
Historically I wouldn't argue for this proposal, if everyone used email for sending small memo-like messages. But increasingly email is used as a universal point-to-point file transfer server for fairly large files, and having to push those files up the slow side of an asymmetric pipe *twice* is not user-friendly. (For frequent correspondents I set up shared DAV folders on my web server, accessible over authenticated HTTPS.)
At best, it introduces problems like handling the case where one operation (sending it) works but the other (saving it to sent-mail) fails. How do you resolve that?
If one uses a remote sent folder, these two operations are one.
Eh? Not in my experience, they aren't - although I have thought to myself many times that they SHOULD be.
Thunderbird is notorious for being able to successfully send a message, but failing on the 'Copy to Sent Folder'. When it fails, you have to quit restart TBird before it will start working again.
--
Best regards,
Charles
On Thursday, May 04, 2006 4:34 PM -0400 Charles Marcus <CMarcus@Media-Brokers.com> wrote:
If one uses a remote sent folder, these two operations are one.
Eh? Not in my experience, they aren't - although I have thought to myself many times that they SHOULD be.
Thunderbird is notorious for being able to successfully send a message, but failing on the 'Copy to Sent Folder'. When it fails, you have to quit restart TBird before it will start working again.
Sorry if I wasn't clear. I meant that the proposed single IMAP operation replaces two distinct operations, one IMAP and one SMTP, from the client's perspective. Once the message is accepted by the IMAP server, it's effectively queued for any downstream delivery operation.
Presumably this acceptance isn't to the "Sent" folder but to some intermediate folder representing the output queue. Or it's to the Sent folder but with some kind of queue-pending flag that's cleared once the message is successfully handed off to the MTA. The SMAP extension appears to implement the latter design. This requires some kind of queue-runner process to periodically retry failed transmissions.
Kenneth Porter wrote:
for sending small memo-like messages. But increasingly email is used as a universal point-to-point file transfer server for fairly large files, and having to push those files up the slow side of an asymmetric pipe *twice* is not user-friendly.
To prevent this, I set up a special mail address, which is automatically cc'ed by my MUA and filtered on the server to end up in Sent folder. So, the second transfer goes over the fast lane, which is not perfect but improves things much. This may be not feasible for every setup, though.
On Thu, 2006-05-04 at 11:46 -0500, Eric Rostetter wrote:
Quoting Marc Perkel <marc@perkel.com>:
- SMAP allows a single transaction to save a new message in the "Sent" folder, and mail it to its designated recipients. IMAP clients need to transmit the message a second time, using SMTP, requiring twice as much bandwidth and time as SMAP to do the same thing.
This would save bandwidth _if_ you use a remote sent-mail folder. Other than that, I see no reason/advantage for it...
Lemonade group is trying to solve this with a separate submission protocol, last I looked (a year or so ago). Maybe they've even finished it.
participants (11)
-
Charles Marcus
-
chester c young
-
Eric Rostetter
-
Jakob Hirsch
-
Jan Kundrát
-
John Peacock
-
Karl Latiss
-
Kenneth Porter
-
Les Mikesell
-
Marc Perkel
-
Timo Sirainen