[Dovecot] Sending email using IMAP
This is something for after the 1.0 release but I think it's important and I'm going to try to figure out how to make it happen. I'd like to see some way to pass outgoing email from Thunderbird back to dovecot through some new command that we would have to make up. Email would be sent back over the IMAP connection and when Dovecot gets it dovecot would hand it off to an SMTP server that would deliver it.
If a crude experimental spec can be written I'll try to find someone on the Thunderbird side to write some sort of module to talk to it.
The reason for this is that I think that the elimination of SMTP from the client is a big step to control spam. The idea being that if IMAP can transfer outgoing mail the SMTP wouldn't be necessary for clients and we can block port 25 on windows machines and viruses can't send email. And the virus wouldn't have access to the IMAP password so viruses can't authenticate to send mail.
So - the key question is - what would it take to create an outgoing spec for sending email over IMAP? Like to see something clean and simple.
also sprach Marc Perkel marc@perkel.com [2006.11.02.2343 +0100]:
This is something for after the 1.0 release but I think it's important and I'm going to try to figure out how to make it happen. I'd like to see some way to pass outgoing email from Thunderbird back to dovecot through some new command that we would have to make up. Email would be sent back over the IMAP connection and when Dovecot gets it dovecot would hand it off to an SMTP server that would deliver it.
FWIW, courier already allows this by way of a special folder. You configure Thunderbird to send mail to the discard port, or using e.g. /bin/true, and to store a copy of sent mail in the .outgoing folder. The courier mail server then takes all messages in this folder and sends them on. No module required on the client side, no protocol modifications.
-- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
"you don't sew with a fork, so i see no reason to eat with knitting needles." -- miss piggy, on eating chinese food
On Thu, 2006-11-02 at 14:43 -0800, Marc Perkel wrote:
The reason for this is that I think that the elimination of SMTP from the client is a big step to control spam. The idea being that if IMAP can transfer outgoing mail the SMTP wouldn't be necessary for clients and we can block port 25 on windows machines and viruses can't send email. And the virus wouldn't have access to the IMAP password so viruses can't authenticate to send mail.
Here in Finland port 25 is already blocked by all the major ISPs. Only the ISP's own SMTP server can be used which also typically limits how fast mails can be sent through it.
I'm using submission port (rfc2476) nowadays for sending my own mail to my SMTP server. Submission port in general is supposed to require authentication from clients.
I think using the submission port is just as good for blocking spam as it would be to send mails via IMAP. Both work only as long as viruses don't use your email client directly and don't dig up the password from the client's configuration.
On Fri, Nov 03, 2006 at 01:01:19AM +0200, Timo Sirainen wrote:
I think using the submission port is just as good for blocking spam as it would be to send mails via IMAP. Both work only as long as viruses don't use your email client directly and don't dig up the password from the client's configuration.
They do. Many Windows spammer-worms simply use MAPI (the mail libraries used by Outlook) so they can trivially use your SMTP configuration and password. Once mail-via-IMAP gets widely used, spammer worms will adapt.
GeertOn Fri, 2006-11-03 at 01:01 +0200, Timo Sirainen wrote:
I'm using submission port (rfc2476) nowadays for sending my own mail to my SMTP server. Submission port in general is supposed to require authentication from clients.
I also require the From: and envelope mail address to match one of the addresses that the logged-in user owns. That not only stops people from impersonating each other but would also stop a virus using the MAPI library (now, if the virus uses that user's From: address then we know who is to blame too...)
johannes
Why not use the smtp *submission* port (and leave 25 disabled)? Also, SMTP auth is a good thing. Much better than the old cowboy days of just trusting some networks..
I look back at the mail submission over pop.. and shudder.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 2 Nov 2006, Jason Fesler wrote:
Why not use the smtp *submission* port (and leave 25 disabled)? Also, SMTP auth is a good thing. Much better than the old cowboy days of just trusting some networks..
Well, one intention for mail via IMAP is that most people keep a copy in their Sent folder, which is located remotely as well - in contrast to POP3. So, you have only one transmission of the (same) contents.
Before you mention DSL, cable etc.pp.: there still people out there who either cannot gain a well enough connection (for whatever reason, be it a technical one or just money) or must share the line with plenty of others or think about roaming people using GSM or UMTS.
I don't advocate Send-Mail-Via-Imap heavily, but I know the pros of it for myself. There is another one: Some mail clients have a really bad SMTP AUTH / TLS implementation, in opposite to IMAP.
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux)
iQEVAwUBRUsAFC9SORjhbDpvAQLU/Qf+OnhwazacUkrkc6Str4CyGs7B7nLkRz+5 DERdO/GnZBT2hJfHCf7q0Zd/WGKOaycxMJfJcv1YM4YjL+GJTpVD4OaLKasAhnua LK4DD06PvMEBDAQ5wd2vbmh2iPt1xdTYuVNBqHOipUubdUwPFX3uC1GHHT3VTi18 tQ0+5E3ywDnskv1gtzlpeAs+zCxx5MRmAwe+f/RW44qU5Vxb7m2+ZJeN2+ul1HKg XXA73XOe1h6AagFZ8TZwQKJRTkDfTc9pn4ixuLZZ10Mkxnbjmzia5g56qxkJZoLK rF13tuYLDn8VyJsDw2ZmKBbjN2m15YJwP9aWZkVsAYuJb+rbrxtmbQ== =YUae -----END PGP SIGNATURE-----
Steffen Kaiser escribió:
-----BEGIN PGP SIGNED MESSAGE----- Well, one intention for mail via IMAP is that most people keep a copy in their Sent folder, which is located remotely as well - in contrast to POP3. So, you have only one transmission of the (same) contents.
You don't need send-via-IMAP for that, we're already doing this without it. Just configure your MTA to deliver a copy of sent mail to user's sent folder (and some mechanism for user opt-in if needed) and configure clients to not save the copy. A sieve script to add 'Seen' flag to those messages may also be a good thing to add.
Regards,
Angel Marin http://anmar.eu.org/
also sprach Angel Marin anmar@gmx.net [2006.11.03.1251 +0100]:
You don't need send-via-IMAP for that, we're already doing this without it. Just configure your MTA to deliver a copy of sent mail to user's sent folder (and some mechanism for user opt-in if needed) and configure clients to not save the copy. A sieve script to add 'Seen' flag to those messages may also be a good thing to add.
This seems like going out of your way, and it adds a bunch of headers to the archived mail.
-- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
"even if you persuade me, you won't persuade me." -- aristophanes
martin f krafft escribió:
also sprach Angel Marin anmar@gmx.net [2006.11.03.1251 +0100]:
You don't need send-via-IMAP for that, we're already doing this without it. Just configure your MTA to deliver a copy of sent mail to user's sent folder (and some mechanism for user opt-in if needed) and configure clients to not save the copy. A sieve script to add 'Seen' flag to those messages may also be a good thing to add.
This seems like going out of your way, and it adds a bunch of headers to the archived mail.
But it makes dialup user's life a lot easier without much configuration overhead (one extra delivery on your MTA and make your MDA set the 'Seen' flag).
The extra headers are even useful as you'll have a copy of the message that's much like the real one delivered, and if you don't want them then configure your MDA to not archive them.
-- Angel Marin http://anmar.eu.org/
On 3.11.2006, at 10.38, Steffen Kaiser wrote:
Why not use the smtp *submission* port (and leave 25 disabled)? Also, SMTP auth is a good thing. Much better than the old cowboy
days of just trusting some networks..Well, one intention for mail via IMAP is that most people keep a
copy in their Sent folder, which is located remotely as well - in
contrast to POP3. So, you have only one transmission of the (same)
contents.
There are already some other SMTP/IMAP extensions created for that
purpose by Lemonade IETF group, which I think is a better way to do
this.
There is another one: Some mail clients have a really bad SMTP
AUTH / TLS implementation, in opposite to IMAP.
And how many such clients support sending mail via IMAP? :)
I guess it would already work with most clients if you specifically
save the message to a specific mailbox, instead of just clicking the
normal send-button. But I doubt anyone would actually want to use
that way.
Am Donnerstag, 2. November 2006 23:43 schrieb Marc Perkel:
email. And the virus wouldn't have access to the IMAP password so
Why not?
Greetings,
Gunter
-- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ "whitespace" - Programming language where only whitespace counts Most modern programming languages do not consider white space characters (spaces, tabs and newlines) syntax, ignoring them, as if they weren't there. Whitespace is a language that seeks to redress the balance. Any non whitespace characters are ignored; only spaces, tabs and newlines are considered syntax. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+PGP-verschlüsselte Mails bevorzugt! +
On Fri, November 3, 2006 12:09 pm, Marc Perkel wrote:
Gunter Ohrner wrote:
Am Donnerstag, 2. November 2006 23:43 schrieb Marc Perkel:
email. And the virus wouldn't have access to the IMAP password so
Why not?
Because the virus wouldn't have the password.
That doesn't answer the question. Why would the IMAP password be any less accessible to a virus than the SMTP password? (For that matter, what you just used was "proof by assertion" which is meaningless. "The virus wouldn't have access to the IMAP password because the virus wouldn't have the password.")
Jim Trigg
On Fri, Nov 03, 2006 at 12:30:11PM -0500, Jim Trigg wrote:
On Fri, November 3, 2006 12:09 pm, Marc Perkel wrote:
Gunter Ohrner wrote:
Am Donnerstag, 2. November 2006 23:43 schrieb Marc Perkel:
email. And the virus wouldn't have access to the IMAP password so
Why not?
Because the virus wouldn't have the password.
That doesn't answer the question. Why would the IMAP password be any less accessible to a virus than the SMTP password? (For that matter, what you just used was "proof by assertion" which is meaningless. "The virus wouldn't have access to the IMAP password because the virus wouldn't have the password.")
Not sure if this is where either of you are going, but...
If people are foolish enough to save their account's password on-disk, then a virus (given enough intelligence) will have access to it. Yes, it means that you'll have to type it in once per startup of the e-mail client, but I for one leave mine running -- and use hibernate.
--
Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: sfs@umn.edu Office of Information Technology Voice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
Jim Trigg wrote:
On Fri, November 3, 2006 12:09 pm, Marc Perkel wrote:
Gunter Ohrner wrote:
Am Donnerstag, 2. November 2006 23:43 schrieb Marc Perkel:
email. And the virus wouldn't have access to the IMAP password so
Why not?
Because the virus wouldn't have the password.
That doesn't answer the question. Why would the IMAP password be any less accessible to a virus than the SMTP password? (For that matter, what you just used was "proof by assertion" which is meaningless. "The virus wouldn't have access to the IMAP password because the virus wouldn't have the password.")
Jim Trigg
IMAP requires a password. SMTP it's optional. I think that consumer SMTP should be replaced with not only something that requires a password, but that the user has to log into the account that they are sending email from. SMTP doesn't have to be tied to IMAP accounts. If you have an SMTP account you can spoof anyone. My idea with IMAP sending is to deny the ability of the sender to use a different email address that the one that they are logged into. This is to prevent spam and spoofing.
On Fri, Nov 03, 2006 at 10:36:13AM -0800, Marc Perkel wrote:
Jim Trigg wrote:
On Fri, November 3, 2006 12:09 pm, Marc Perkel wrote:
Gunter Ohrner wrote:
Am Donnerstag, 2. November 2006 23:43 schrieb Marc Perkel:
email. And the virus wouldn't have access to the IMAP password so
Why not?
Because the virus wouldn't have the password.
That doesn't answer the question. Why would the IMAP password be any less accessible to a virus than the SMTP password? (For that matter, what you just used was "proof by assertion" which is meaningless. "The virus wouldn't have access to the IMAP password because the virus wouldn't have the password.")
Jim Trigg
IMAP requires a password. SMTP it's optional.
Not at the University of Minnesota. We require ESMTP STARTTLS/AUTH over the standard mail submission port (587).
I think that consumer SMTP should be replaced with not only something that requires a password, but that the user has to log into the account that they are sending email from.
Not necessary -- configure your mail server to match your policy requirements.
SMTP doesn't have to be tied to IMAP accounts.
Correct. In fact, you can have multiple IMAP accounts configured in an e-mail client, but may have only 1 SMTP account set up (which doesn't even have to match up with any of the IMAP accounts). At least in Thunderbird.
If you have an SMTP account you can spoof anyone.
That is an SMTP issue in general, not an authentication issue. If you have Internet access at all, you can spoof anyone by simply connecting to a remote port 25 and sending to your heart's content without needing any passwords...
My idea with IMAP sending is to deny the ability of the sender to use a different email address that the one that they are logged into. This is to prevent spam and spoofing.
You can certainly do this on your mail server, but you can't force every other server on the Internet to do the same. :)
--
Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: sfs@umn.edu Office of Information Technology Voice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
Steven F Siirila wrote:
On Fri, Nov 03, 2006 at 10:36:13AM -0800, Marc Perkel wrote:
Jim Trigg wrote:
On Fri, November 3, 2006 12:09 pm, Marc Perkel wrote:
Gunter Ohrner wrote:
Am Donnerstag, 2. November 2006 23:43 schrieb Marc Perkel:
email. And the virus wouldn't have access to the IMAP password so
Why not?
Because the virus wouldn't have the password.
That doesn't answer the question. Why would the IMAP password be any less accessible to a virus than the SMTP password? (For that matter, what you just used was "proof by assertion" which is meaningless. "The virus wouldn't have access to the IMAP password because the virus wouldn't have the password.")
Jim Trigg
IMAP requires a password. SMTP it's optional.
Not at the University of Minnesota. We require ESMTP STARTTLS/AUTH over the standard mail submission port (587).
OK - but the rest of the world varies from what the University of Minnesota does.
I think that consumer SMTP should be replaced with not only something that requires a password, but that the user has to log into the account that they are sending email from.
Not necessary -- configure your mail server to match your policy requirements.
Yes but it's optional. I've done it that way but others don't.
SMTP doesn't have to be tied to IMAP accounts.
Correct. In fact, you can have multiple IMAP accounts configured in an e-mail client, but may have only 1 SMTP account set up (which doesn't even have to match up with any of the IMAP accounts). At least in Thunderbird.
But with outgoing IMAP you wouldn't have to configure outgoing email at all.
If you have an SMTP account you can spoof anyone.
That is an SMTP issue in general, not an authentication issue. If you have Internet access at all, you can spoof anyone by simply connecting to a remote port 25 and sending to your heart's content without needing any passwords...
But you could limit a domain to require that the sending email come from the account of the receiving email.
My idea with IMAP sending is to deny the ability of the sender to use a different email address that the one that they are logged into. This is to prevent spam and spoofing.
You can certainly do this on your mail server, but you can't force every other server on the Internet to do the same. :)
But I think if we tightend up the spec some we could eliminate most spam.
On Fri, Nov 03, 2006 at 11:00:08AM -0800, Marc Perkel wrote:
But with outgoing IMAP you wouldn't have to configure outgoing email at all.
How would SMTP errors (e.g. user does not exist) be returned? With a bounce mail?
And what if a user is over quota? He wouldn't be able to send mail anymore either?
GeertOn Friday 03 November 2006 13:00, Marc Perkel wrote:
IMAP requires a password. SMTP it's optional.
Not at the University of Minnesota. We require ESMTP STARTTLS/AUTH over the standard mail submission port (587).
OK - but the rest of the world varies from what the University of Minnesota does.
This is absurd. Any responsible mail server will require some form of control over the clients it allows to relay. If yours does not, please see http://www.ordb.org/submit/ .
Yes, you might choose to allow unauthenticated relaying for clients in netblocks under your direct control. But that is also reasonable, since when you get an abuse report you can immediately cut off the relaying client.
It's a well-established best practice now to require SMTP AUTH for relaying. Every mail server I have set up or currently administer is exactly like what Steven describes. ISTM that the U. of Minnesota is quite in the mainstream.
I think that consumer SMTP should be replaced with not only something that requires a password, but that the user has to log into the account that they are sending email from.
FWIW, I think it has been replaced. If I were to authenticate to send through GMX, they would not allow me to use a different sender address. Probably all major freemail providers, and many ISPs, are already doing this.
Not necessary -- configure your mail server to match your policy requirements.
Yes but it's optional. I've done it that way but others don't.
Everyone is (or should be, sigh) responsible for abuse that comes from their networks.
But with outgoing IMAP you wouldn't have to configure outgoing email at all.
You'd simply have to create a new standard and get most server and client software to implement it. Piece of cake. :)
But I think if we tightend up the spec some we could eliminate most spam.
Many talented people have worked tirelessly to find one, but alas,
there is no FUSSP in sight.
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: headerOn Fri, 2006-11-03 at 11:00 -0800, Marc Perkel wrote:
Steven F Siirila wrote:
On Fri, Nov 03, 2006 at 10:36:13AM -0800, Marc Perkel wrote: [...]
IMAP requires a password. SMTP it's optional.
Not at the University of Minnesota. We require ESMTP STARTTLS/AUTH over the standard mail submission port (587).
The question is: How do you enforce it on submission via port 25?
OK - but the rest of the world varies from what the University of Minnesota does.
Not all of it. And if, then it is their choice. Perhaps you should submit an RFC for a better SMTP requiring authentication and other anti-spam meassures.
Bernd-- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services
On Fri, Nov 03, 2006 at 11:37:08PM +0100, Bernd Petrovitsch wrote:
On Fri, 2006-11-03 at 11:00 -0800, Marc Perkel wrote:
Steven F Siirila wrote:
On Fri, Nov 03, 2006 at 10:36:13AM -0800, Marc Perkel wrote: [...]
IMAP requires a password. SMTP it's optional.
Not at the University of Minnesota. We require ESMTP STARTTLS/AUTH over the standard mail submission port (587).
The question is: How do you enforce it on submission via port 25?
We do allow the same thing over port 25, but only for backward compatibility. (If you try using either port without STARTTLS+AUTH, it will not work.) And of course for those non-standard MUAs (i.e. older Outlook) we also do support port 465 (SSL) and require AUTH there as well.
--
Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: sfs@umn.edu Office of Information Technology Voice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
On Fri, 2006-11-03 at 17:10 -0600, Steven F Siirila wrote:
On Fri, Nov 03, 2006 at 11:37:08PM +0100, Bernd Petrovitsch wrote:
On Fri, 2006-11-03 at 11:00 -0800, Marc Perkel wrote:
Steven F Siirila wrote:
On Fri, Nov 03, 2006 at 10:36:13AM -0800, Marc Perkel wrote: [...]
IMAP requires a password. SMTP it's optional.
Not at the University of Minnesota. We require ESMTP STARTTLS/AUTH over the standard mail submission port (587).
The question is: How do you enforce it on submission via port 25?
We do allow the same thing over port 25, but only for backward compatibility. (If you try using either port without STARTTLS+AUTH, it will not work.) And of course for those non-standard MUAs (i.e. older Outlook) we also do support port 465 (SSL) and require AUTH there as well.
Sorry, my above question was bad worded - it should have been: The question is: How do you enforce submission via the submission port (and inhibit submission via port 25)?
Bernd-- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services
On Sat, Nov 04, 2006 at 09:40:44PM +0100, Bernd Petrovitsch wrote:
On Fri, 2006-11-03 at 17:10 -0600, Steven F Siirila wrote:
On Fri, Nov 03, 2006 at 11:37:08PM +0100, Bernd Petrovitsch wrote:
On Fri, 2006-11-03 at 11:00 -0800, Marc Perkel wrote:
Steven F Siirila wrote:
On Fri, Nov 03, 2006 at 10:36:13AM -0800, Marc Perkel wrote: [...]
IMAP requires a password. SMTP it's optional.
Not at the University of Minnesota. We require ESMTP STARTTLS/AUTH over the standard mail submission port (587).
The question is: How do you enforce it on submission via port 25?
We do allow the same thing over port 25, but only for backward compatibility. (If you try using either port without STARTTLS+AUTH, it will not work.) And of course for those non-standard MUAs (i.e. older Outlook) we also do support port 465 (SSL) and require AUTH there as well.
Sorry, my above question was bad worded - it should have been: The question is: How do you enforce submission via the submission port (and inhibit submission via port 25)?
We don't REQUIRE it (yet), but we strongly encourage it.
--
Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: sfs@umn.edu Office of Information Technology Voice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
On Sat 04 Nov 2006 22:40, Bernd Petrovitsch wrote:
On Fri, 2006-11-03 at 17:10 -0600, Steven F Siirila wrote:
On Fri, Nov 03, 2006 at 11:37:08PM +0100, Bernd Petrovitsch wrote:
On Fri, 2006-11-03 at 11:00 -0800, Marc Perkel wrote:
Steven F Siirila wrote:
On Fri, Nov 03, 2006 at 10:36:13AM -0800, Marc Perkel wrote:
[...]
IMAP requires a password. SMTP it's optional.
Not at the University of Minnesota. We require ESMTP STARTTLS/AUTH over the standard mail submission port (587).
The question is: How do you enforce it on submission via port 25?
We do allow the same thing over port 25, but only for backward compatibility. (If you try using either port without STARTTLS+AUTH, it will not work.) And of course for those non-standard MUAs (i.e. older Outlook) we also do support port 465 (SSL) and require AUTH there as well.
Sorry, my above question was bad worded - it should have been: The question is: How do you enforce submission via the submission port (and inhibit submission via port 25)?
Postfix can be configured in this manner, although I am not really sure what it gains you.
--
Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Marc Perkel wrote:
IMAP requires a password. SMTP it's optional. I think that consumer SMTP should be replaced with not only something that requires a password, but that the user has to log into the account that they are sending email from. SMTP doesn't have to be tied to IMAP accounts. If you have an SMTP account you can spoof anyone. My idea with IMAP sending is to deny the ability of the sender to use a different email address that the one that they are logged into. This is to prevent spam and spoofing.
I don't know what SMTP software you're using, but on my servers port 587 *requires* authentication and port 25 requires authentication in order to relay mail. Of course, once authenticated, you can put anything you want for sender address but that, too, can be prevented with a reasonable MTA and correct configuration.
Basically, my point is that you can configure your SMTP server to enforce whatever restrictions you want on the envelope or even the headers. Just because you can configure it to be an open relay doesn't mean you have to have it configured that way.
-- William Astle Lexicom Ltd. Phone: +1-403-262-6610 Long Distance: 1-877-426-6277 Email: astle@lexi.net
William Astle wrote:
Marc Perkel wrote:
IMAP requires a password. SMTP it's optional. I think that consumer SMTP should be replaced with not only something that requires a password, but that the user has to log into the account that they are sending email from. SMTP doesn't have to be tied to IMAP accounts. If you have an SMTP account you can spoof anyone. My idea with IMAP sending is to deny the ability of the sender to use a different email address that the one that they are logged into. This is to prevent spam and spoofing.
I don't know what SMTP software you're using, but on my servers port 587 *requires* authentication and port 25 requires authentication in order to relay mail. Of course, once authenticated, you can put anything you want for sender address but that, too, can be prevented with a reasonable MTA and correct configuration.
Basically, my point is that you can configure your SMTP server to enforce whatever restrictions you want on the envelope or even the headers. Just because you can configure it to be an open relay doesn't mean you have to have it configured that way.
It does on mine as well. But I do not control the rest of the world. If everyone used this standard then spam would drop drastically.
To make it short : would it not be better to discuss such a proposed standard extension on the imap protocol list (Imap-protocol@u.washington.edu) rather than on an imap server list ? It would not help much to implement this in one server only.
Yours JC
On Fri, November 3, 2006 1:36 pm, Marc Perkel wrote:
Jim Trigg wrote:
On Fri, November 3, 2006 12:09 pm, Marc Perkel wrote:
Gunter Ohrner wrote:
Am Donnerstag, 2. November 2006 23:43 schrieb Marc Perkel:
email. And the virus wouldn't have access to the IMAP password so Why not? Because the virus wouldn't have the password.
That doesn't answer the question. Why would the IMAP password be any less accessible to a virus than the SMTP password? (For that matter, what you just used was "proof by assertion" which is meaningless. "The virus wouldn't have access to the IMAP password because the virus wouldn't have the password.")
IMAP requires a password. SMTP it's optional. I think that consumer SMTP should be replaced with not only something that requires a password, but that the user has to log into the account that they are sending email from. SMTP doesn't have to be tied to IMAP accounts. If you have an SMTP account you can spoof anyone. My idea with IMAP sending is to deny the ability of the sender to use a different email address that the one that they are logged into. This is to prevent spam and spoofing.
Sorry, I thought the whole discussion was IMAP-sending versus SMTP-AUTH. Any submission port that is using neither SMTP-AUTH nor pop/imap-before-smtp is not worth considering, and any that is using such effectively requires a password to send email. As for preventing spoofing, there are scenarios in which it is necessary (real-life case study available on request).
Jim
On Friday 03 November 2006 19:36, Marc Perkel took the opportunity to say:
IMAP requires a password. SMTP it's optional. I think that consumer SMTP should be replaced with not only something that requires a password, but that the user has to log into the account that they are sending email from. SMTP doesn't have to be tied to IMAP accounts. If you have an SMTP account you can spoof anyone. My idea with IMAP sending is to deny the ability of the sender to use a different email address that the one that they are logged into. This is to prevent spam and spoofing.
You never give up, do you? Every time you propose submission by IMAP many people tell you that there is no fundamental difference between that and authenticated SMTP. Every ISP in the world, including the large-scale spammers who act as ISPs themselves, would have to employ suitable policies to avoid transmitting spoofed email. SMTP will still be used to transmit the mail to its destinations. Real authenticity is achieved using digital signatures, e.g. DKIM, in combination with SPF and your personal trust preferences. For example, GMail allows their users to send mail from any email address they can demonstrate that they own. That's good, that's what yoy want, and it is completely unrelated to IMAP.
-- Magnus Holmgren holmgren@lysator.liu.se (No Cc of list mail needed, thanks)
Magnus Holmgren wrote:
On Friday 03 November 2006 19:36, Marc Perkel took the opportunity to say:
IMAP requires a password. SMTP it's optional. I think that consumer SMTP should be replaced with not only something that requires a password, but that the user has to log into the account that they are sending email from. SMTP doesn't have to be tied to IMAP accounts. If you have an SMTP account you can spoof anyone. My idea with IMAP sending is to deny the ability of the sender to use a different email address that the one that they are logged into. This is to prevent spam and spoofing.
You never give up, do you? Every time you propose submission by IMAP many people tell you that there is no fundamental difference between that and authenticated SMTP.
I remembered another recent neverending thread "The future of email is SQL" by the same author. One of these days he'll hit on a million dollar idea. This ain't it tho... So please stop wasting Timo's precious time with it! Thanks, Ken A. Pacific.Net
Every ISP in the world, including the large-scale
spammers who act as ISPs themselves, would have to employ suitable policies to avoid transmitting spoofed email. SMTP will still be used to transmit the mail to its destinations. Real authenticity is achieved using digital signatures, e.g. DKIM, in combination with SPF and your personal trust preferences. For example, GMail allows their users to send mail from any email address they can demonstrate that they own. That's good, that's what yoy want, and it is completely unrelated to IMAP.
Magnus Holmgren wrote:
On Friday 03 November 2006 19:36, Marc Perkel took the opportunity to say:
IMAP requires a password. SMTP it's optional. I think that consumer SMTP should be replaced with not only something that requires a password, but that the user has to log into the account that they are sending email from. SMTP doesn't have to be tied to IMAP accounts. If you have an SMTP account you can spoof anyone. My idea with IMAP sending is to deny the ability of the sender to use a different email address that the one that they are logged into. This is to prevent spam and spoofing.
You never give up, do you? Every time you propose submission by IMAP many people tell you that there is no fundamental difference between that and authenticated SMTP. Every ISP in the world, including the large-scale spammers who act as ISPs themselves, would have to employ suitable policies to avoid transmitting spoofed email. SMTP will still be used to transmit the mail to its destinations. Real authenticity is achieved using digital signatures, e.g. DKIM, in combination with SPF and your personal trust preferences. For example, GMail allows their users to send mail from any email address they can demonstrate that they own. That's good, that's what yoy want, and it is completely unrelated to IMAP.
There is a fundamental difference.
You can use SMTP or authenticated SMTP to authenticate and send email through ANY server and it doesn't require that the authentication have anything to do with the authentication of the IMAP account. If you had an IMAP protocol to send email then you could lock out the SMTP protocols for end users and force the to have to authenticate using the same protocols. This gives you several advantages. You can make it so that the from address and reply to address match the IMAP account prohibiting spoofing of email addresses. It can be used to prevent user mischief.
It eliminated 50% of user setup in that once you set up IMAP you need not set up oupgoing email.
It gets you around port blocking. If you can receive email you can send email This is good for those traveling who have trouble finding a working SMTP server.
A server who advertizes through DNS that they have these restrictions can prevent spam as other servers can reject spam from that domain that comes from outside the rules advertized.
Why use 2 protocols when you can use one?
On Sat, Nov 04, 2006 at 06:53:29AM -0800, Marc Perkel wrote:
Magnus Holmgren wrote:
On Friday 03 November 2006 19:36, Marc Perkel took the opportunity to say:
IMAP requires a password. SMTP it's optional. I think that consumer SMTP should be replaced with not only something that requires a password, but that the user has to log into the account that they are sending email from. SMTP doesn't have to be tied to IMAP accounts. If you have an SMTP account you can spoof anyone. My idea with IMAP sending is to deny the ability of the sender to use a different email address that the one that they are logged into. This is to prevent spam and spoofing.
You never give up, do you? Every time you propose submission by IMAP many people tell you that there is no fundamental difference between that and authenticated SMTP. Every ISP in the world, including the large-scale spammers who act as ISPs themselves, would have to employ suitable policies to avoid transmitting spoofed email. SMTP will still be used to transmit the mail to its destinations. Real authenticity is achieved using digital signatures, e.g. DKIM, in combination with SPF and your personal trust preferences. For example, GMail allows their users to send mail from any email address they can demonstrate that they own. That's good, that's what yoy want, and it is completely unrelated to IMAP.
There is a fundamental difference.
- You can use SMTP or authenticated SMTP to authenticate and send email through ANY server and it doesn't require that the authentication have anything to do with the authentication of the IMAP account. If you had an IMAP protocol to send email then you could lock out the SMTP protocols for end users and force the to have to authenticate using the same protocols. This gives you several advantages. You can make it so that the from address and reply to address match the IMAP account prohibiting spoofing of email addresses. It can be used to prevent user mischief.
You can do the same thing with authenticated SMTP (tie the from address and reply to address to the authenticated user).
- It eliminated 50% of user setup in that once you set up IMAP you need not set up oupgoing email.
Minor.
- It gets you around port blocking. If you can receive email you can send email This is good for those traveling who have trouble finding a working SMTP server.
So does standardizing on the already-established submission port (587).
- A server who advertizes through DNS that they have these restrictions can prevent spam as other servers can reject spam from that domain that comes from outside the rules advertized.
If you can get LOTS of folks to advertise something via DNS, I have much better ways to reject spam. For example, get IP network owners to publish IP addresses which are never authorized to send direct-to-MX mail. This would eliminate tons of spam from zombies on dynamic IP addresses.
- Why use 2 protocols when you can use one?
Because they're industry standards and in wide use.
--
Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: sfs@umn.edu Office of Information Technology Voice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
On Fri, 2006-11-03 at 12:36, Marc Perkel wrote:
IMAP requires a password. SMTP it's optional. I think that consumer SMTP should be replaced with not only something that requires a password, but that the user has to log into the account that they are sending email from. SMTP doesn't have to be tied to IMAP accounts. If you have an SMTP account you can spoof anyone. My idea with IMAP sending is to deny the ability of the sender to use a different email address that the one that they are logged into. This is to prevent spam and spoofing.
You are talking about implementation details, not protocols here. Assuming you could send over IMAP, why do you think it would any more likely that spoofing would be blocked by all implementations than with authenticated smtp or that all accounts that accepted IMAP logins would be valid sending addresses?
-- Les Mikesell lesmikesell@gmail.com
On Fri, 2006-11-03 at 11:09, Marc Perkel wrote:
email. And the virus wouldn't have access to the IMAP password so
Why not?
Because the virus wouldn't have the password.
Beg your pardon, but the biggest email virus spreader of all doesn't use smtp, and does send through a service that needs authentication. You are on the wrong track here.
-- Les Mikesell lesmikesell@gmail.com
I see only one way to get rid of spam: Hashcash type of thing being
required by everyone, but with some kind of a protocol to make
mailing lists be able to work.
Of course, that won't work if the spam is sent only by some botnets
using tons of computers. To fix that everyone would have to start
using operating systems which don't allow you to accidentally run all
sorts of botnet software. And such operating systems don't exist at
the moment. Although OLTP's sounds promising.
participants (20)
-
/dev/rob0
-
Angel Marin
-
Bernd Petrovitsch
-
Geert Hendrickx
-
Gunter Ohrner
-
Jakob Curdes
-
Jan Kundrat
-
Jason Fesler
-
Jim Trigg
-
Johannes Berg
-
Ken A
-
Les Mikesell
-
Magnus Holmgren
-
Marc Perkel
-
martin f krafft
-
Peter Nixon
-
Steffen Kaiser
-
Steven F Siirila
-
Timo Sirainen
-
William Astle