[Dovecot] vpopmail
I was running 1.0.beta3 code with no problems. I recently switched to 1.0.beta8 and I noticed that vpopmail's pop-before-smtp functionality stopped working. I am using vpopmail authentication. Has anyone else encountered this problem?
Thank you.
Kenneth Tan
C J Kenneth Tan, PhD OptimaNumerics Ltd Telephone: +44 798 941 7838 E-mail: cjtan@OptimaNumerics.com Telephone: +44 207 099 4428 Web: http://www.OptimaNumerics.com Facsimile: +44 207 100 4572
C J Kenneth Tan -- OptimaNumerics <cjtan@OptimaNumerics.com> writes:
I was running 1.0.beta3 code with no problems. I recently switched to 1.0.beta8 and I noticed that vpopmail's pop-before-smtp functionality stopped working. I am using vpopmail authentication. Has anyone else encountered this problem?
Don't use POP-before-SMTP. It's dangerous.
Don't use POP-before-SMTP. It's a major security risk.
Don't use POP-before-SMTP, it allows viruses to relay mail.
if you still want it, check the release notes and the Dovecot Wiki, either has the relevant information.
-- Matthias Andree
Matthias,
Thanks for the pointer. I see that you put on the Wiki claiming that SMTP AUTH is the alternative.
On 2006-06-02 11:35 +0200 Matthias Andree (matthias.andree@gmx.de) wrote:
C J Kenneth Tan -- OptimaNumerics <cjtan@OptimaNumerics.com> writes:
I was running 1.0.beta3 code with no problems. I recently switched to 1.0.beta8 and I noticed that vpopmail's pop-before-smtp functionality stopped working. I am using vpopmail authentication. Has anyone else encountered this problem?
Don't use POP-before-SMTP. It's dangerous.
Don't use POP-before-SMTP. It's a major security risk.
Don't use POP-before-SMTP, it allows viruses to relay mail.
if you still want it, check the release notes and the Dovecot Wiki, either has the relevant information.
I was reporting that using 1.0.beta8, vpopmail's pop-before-smtp functionality stopped working. Is intentional? I didn't see any relevant changes in the ChangeLog file.
Would you be able to explain to me how SMTP AUTH prevents virus relay that cannot be accomplished with POP-before-SMTP?
Would you be able to also explain what do you mean by "dangerous"?
Would you be able to also explain what do you mean by "major security risk"?
Thank you.
Ken
C J Kenneth Tan, PhD OptimaNumerics Ltd Telephone: +44 798 941 7838 E-mail: cjtan@OptimaNumerics.com Telephone: +44 207 099 4428 Web: http://www.OptimaNumerics.com Facsimile: +44 207 100 4572
On Sunday 04 June 2006 12:34, C J Kenneth Tan -- OptimaNumerics took the opportunity to write:
- Would you be able to explain to me how SMTP AUTH prevents virus relay that cannot be accomplished with POP-before-SMTP?
With POP-before-SMTP: You check your mail with POP -> you can then send mail for, say, 30 minutes, but so can viruses, from any computer behind the same NAT box even. With SMTP AUTH: Password must be supplied with every mail transmission, which means that viruses must steal it from you, which is far from impossible but at least presents an obstacle.
Would you be able to also explain what do you mean by "dangerous"?
Would you be able to also explain what do you mean by "major security risk"?
I guess the answer is the same to these questions.
-- Magnus Holmgren holmgren@lysator.liu.se (No Cc of list mail needed, thanks)
Magnus,
On 2006-06-04 14:27 +0200 Magnus Holmgren (holmgren@lysator.liu.se) wrote:
On Sunday 04 June 2006 12:34, C J Kenneth Tan -- OptimaNumerics took the opportunity to write:
- Would you be able to explain to me how SMTP AUTH prevents virus relay that cannot be accomplished with POP-before-SMTP?
With POP-before-SMTP: You check your mail with POP -> you can then send mail for, say, 30 minutes, but so can viruses, from any computer behind the same NAT box even. With SMTP AUTH: Password must be supplied with every mail transmission, which means that viruses must steal it from you, which is far from impossible but at least presents an obstacle.
I see the argument. The objective here is to allow relay by Linux laptops running qmail which receive mail from Pine running on the laptops. SMTP server would have SMTP level virus and spam check to counter this problem.
Thank you.
Kenneth Tan
C J Kenneth Tan, PhD OptimaNumerics Ltd Telephone: +44 798 941 7838 E-mail: cjtan@OptimaNumerics.com Telephone: +44 207 099 4428 Web: http://www.OptimaNumerics.com Facsimile: +44 207 100 4572
C J Kenneth Tan -- OptimaNumerics wrote:
I see the argument. The objective here is to allow relay by Linux laptops running qmail which receive mail from Pine running on the laptops.
Either the laptop should be configured to directly talk to the outgoing SMTP server (with SMTP AUTH in place) *OR* the laptop should be configured to send all e-mail via qmail on localhost (in which case no authentication is required at all). I don't see any reason to mess around with hacks like POP before SMTP here...
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
John,
On 2006-06-04 14:12 -0400 John Peacock (jpeacock@rowman.com) wrote:
C J Kenneth Tan -- OptimaNumerics wrote:
I see the argument. The objective here is to allow relay by Linux laptops running qmail which receive mail from Pine running on the laptops.
Either the laptop should be configured to directly talk to the outgoing SMTP server (with SMTP AUTH in place) *OR* the laptop should be configured to send all e-mail via qmail on localhost (in which case no authentication is required at all). I don't see any reason to mess around with hacks like POP before SMTP here...
The current setup:
- Pine configured to send mail via localhost (qmail)
- qmail on localhost send mail to SMTP server
- SMTP server allow/reject connections based on POP-before-SMTP
- SMTP server performs spam and virus checks
qmail with vpopmail's POP-before-SMTP is actually much less setup work because it works right out of the box.
Ken
C J Kenneth Tan, PhD OptimaNumerics Ltd Telephone: +44 798 941 7838 E-mail: cjtan@OptimaNumerics.com Telephone: +44 207 099 4428 Web: http://www.OptimaNumerics.com Facsimile: +44 207 100 4572
C J Kenneth Tan -- OptimaNumerics <cjtan@OptimaNumerics.com> writes:
The current setup:
- Pine configured to send mail via localhost (qmail)
- qmail on localhost send mail to SMTP server
- SMTP server allow/reject connections based on POP-before-SMTP
- SMTP server performs spam and virus checks
qmail with vpopmail's POP-before-SMTP is actually much less setup work because it works right out of the box.
Because that's the only thing the decrepit qmail handles. Any modern MTA has evolved quite far from that point. No matter if you prefer Postfix, Exim, Courier, Sendmail or something else but qmail...
-- Matthias Andree
Matthias Andree wrote:
Because that's the only thing the decrepit qmail handles. Any modern MTA has evolved quite far from that point. No matter if you prefer Postfix, Exim, Courier, Sendmail or something else but qmail...
Your criticism of qmail is off-topic for this list, and quite besides the point of the original posters question, which I will restate below without mention of qmail:
The current setup:
- Pine configured to send mail via localhost (MTA)
- MTA on localhost send mail to SMTP server
- SMTP server allow/reject connections based on POP-before-SMTP
- SMTP server performs spam and virus checks
This isn't that unreasonable a setup - because the laptop may not be connected at all times, he wants to have a local MTA on the laptop to deposit mail into while offline. That MTA is configured to relay all mail via his primary MTA, which scans incoming/outgoing mail and delivers it to the appropriate remote MTA. As such, whether he is running postfix or qmail (or Sendmail) *on the laptop*, he wanted to know why POP-before-SMTP broke on his primary server.
It's not that I disagree with you that POP-before-SMTP is suboptimal and should be replaced with AUTH; it's that you are being such an a$$h0le in your anti-qmail fervor, that any wisdom you may be imparting is lost in the vitriol.
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
(cutting down Cc list)
On Mon, 05 Jun 2006, John Peacock wrote:
The current setup:
- Pine configured to send mail via localhost (MTA)
- MTA on localhost send mail to SMTP server
- SMTP server allow/reject connections based on POP-before-SMTP
- SMTP server performs spam and virus checks
This isn't that unreasonable a setup - because the laptop may not be
The setup is unreasonable, we already agreed that POP-before-SMTP alone is unreasonable and dangerous in dynamic-IP environments.
connected at all times, he wants to have a local MTA on the laptop to deposit mail into while offline. That MTA is configured to relay all mail via his primary MTA, which scans incoming/outgoing mail and delivers it to the appropriate remote MTA. As such, whether he is running postfix or qmail (or Sendmail) *on the laptop*, he wanted to know why POP-before-SMTP broke on his primary server.
This was already answered a few posts ago, with the side note that POP-before-SMTP opens security loopholes.
I understand the intentions and the situation (and, as yet another sidestab, "this can happen with betas"), and the chosen MTA that is incapable of SMTP AUTH is a fact that matters here, since the limitations of the MTA cause such crutches as POP-before-SMTP -- and they are quite besides the track given that the chosen MTA claims security.
It's not that I disagree with you that POP-before-SMTP is suboptimal and should be replaced with AUTH; it's that you are being such an a$$h0le in your anti-qmail fervor, that any wisdom you may be imparting is lost in the vitriol.
There's much less emotion ("fervor") in my calling qmail decrepit than you suspect. It would be unwise to not talk about qmail being the agent that caused the POP-before-SMTP dangers.
And, yet another side note, that POP-before-SMTP may fail after software upgrades, is just another reason to replace it.
-- Matthias Andree
John,
On 2006-06-05 12:16 -0400 John Peacock (jpeacock@rowman.com) wrote:
Matthias Andree wrote:
Because that's the only thing the decrepit qmail handles. Any modern MTA has evolved quite far from that point. No matter if you prefer Postfix, Exim, Courier, Sendmail or something else but qmail...
Your criticism of qmail is off-topic for this list, and quite besides the point of the original posters question, which I will restate below without mention of qmail:
In any case, given the circumstances and the timescales, qmail is an "unmovable" item at this point in time.
The current setup:
- Pine configured to send mail via localhost (MTA)
- MTA on localhost send mail to SMTP server
- SMTP server allow/reject connections based on POP-before-SMTP
- SMTP server performs spam and virus checks
This isn't that unreasonable a setup - because the laptop may not be connected at all times, he wants to have a local MTA on the laptop to deposit mail into while offline. That MTA is configured to relay all mail via his primary MTA, which scans incoming/outgoing mail and delivers it to the appropriate remote MTA. As such, whether he is running postfix or qmail (or Sendmail) *on the laptop*, he wanted to know why POP-before-SMTP broke on his primary server.
Exactly!
It's not that I disagree with you that POP-before-SMTP is suboptimal and should be replaced with AUTH; it's that you are being such an a$$h0le in your anti-qmail fervor, that any wisdom you may be imparting is lost in the vitriol.
While I understand that SMTP AUTH may be an excellent solution, I need to take into account our current environment and circumstances. It looks like we need to keep POP-before-SMTP around for a while, possibly move to SMTP AUTH at some point in the future. Would be great if POP-before-SMTP continued working.
Thank you.
Ken
C J Kenneth Tan, PhD OptimaNumerics Ltd Telephone: +44 798 941 7838 E-mail: cjtan@OptimaNumerics.com Telephone: +44 207 099 4428 Web: http://www.OptimaNumerics.com Facsimile: +44 207 100 4572
(Following up to several messages at the same time, to reduce clutter.)
C J Kenneth Tan -- OptimaNumerics <cjtan@OptimaNumerics.com> writes:
This isn't that unreasonable a setup - because the laptop may not be connected at all times, he wants to have a local MTA on the laptop to deposit mail into while offline. That MTA is configured to relay all mail via his primary MTA, which scans incoming/outgoing mail and delivers it to the appropriate remote MTA. As such, whether he is running postfix or qmail (or Sendmail) *on the laptop*, he wanted to know why POP-before-SMTP broke on his primary server.
Exactly!
See if http://wiki.dovecot.org/PopBSMTPAndDovecot helps. It looks relevant, at least if your server uses Dovecot and DRAC.
While I understand that SMTP AUTH may be an excellent solution, I need to take into account our current environment and circumstances. It looks like we need to keep POP-before-SMTP around for a while, possibly move to SMTP AUTH at some point in the future. Would be great if POP-before-SMTP continued working.
For your setup and timelines, probably. For the network as a whole, it wouldn't, sorry.
C J Kenneth Tan -- OptimaNumerics <cjtan@OptimaNumerics.com> writes:
Is this going to be a case of replacing the MTA just because something changed in the POP/IMAP server?
It's an opportunity to migrate setups that should have been switched long ago.
C J Kenneth Tan -- OptimaNumerics <cjtan@OptimaNumerics.com> writes:
Matthias,
On 2006-06-05 18:04 +0200 Matthias Andree (matthias.andree@gmx.de) wrote:
C J Kenneth Tan -- OptimaNumerics <cjtan@OptimaNumerics.com> writes:
I see the argument. The objective here is to allow relay by Linux laptops running qmail
Not a good idea. <http://home.pages.de/~mandree/qmail-bugs.html>
What is not a good idea? Allowing relay? Linux laptops? qmail? If qmail is not a good idea, then unfortunately this is an "unmovable" item. We have a number of things in our environment that prevents us from making such changes, especially given the timescales.
Running qmail is a bad idea for reasons laid out in that document.
SMTP-after-POP (POP-before-SMTP) is a bad idea for reasons given earlier in this thread.
I understand the argument. The environment that we are talking about here consists of Linux laptops, which I have mentioned before, and OpenBSD and Linux mail hosts. Also, while I understand that past performance is no indication of future response times, ClamAV and F-Prot seem to have fairly prompt response.
I can't really judge either, I'm running Antivir on my personal host and Sophos on a client's server -- either with amavisd-new.
Correct me if I am wrong, but this seem to have little to do with the fact that vpopmail authentication to enable POP-before-SMTP in Dovecot 1.0.beta3 and 1.0.beta8 changed.
As far as I can see, the DRAC integration changed in beta4; the Wiki link at the very beginning has information that looks relevant to your problem.
C J Kenneth Tan -- OptimaNumerics <cjtan@OptimaNumerics.com> writes:
I can get qmail-smtpd to do SMTP AUTH, patching against qmail-1.03. I can also get qmail-remote to do SMTP AUTH, patching against qmail-1.03. But I am having trouble getting them to work with qmail-1.03 plus all the other patches that I want.
Which was my case for suggesting a migration.
-- Matthias Andree
On 2006-06-05 23:45 +0200 Matthias Andree (matthias.andree@gmx.de) wrote:
C J Kenneth Tan -- OptimaNumerics <cjtan@OptimaNumerics.com> writes:
This isn't that unreasonable a setup - because the laptop may not be connected at all times, he wants to have a local MTA on the laptop to deposit mail into while offline. That MTA is configured to relay all mail via his primary MTA, which scans incoming/outgoing mail and delivers it to the appropriate remote MTA. As such, whether he is running postfix or qmail (or Sendmail) *on the laptop*, he wanted to know why POP-before-SMTP broke on his primary server.
Exactly!
See if http://wiki.dovecot.org/PopBSMTPAndDovecot helps. It looks relevant, at least if your server uses Dovecot and DRAC.
As far as I can see, the DRAC integration changed in beta4; the Wiki link at the very beginning has information that looks relevant to your problem.
Logically, it didn't sound to me that DRAC nor the info on the Wiki which relies on log file parsing would apply/solve the problem. So I decided that I will roll up my sleeves and dig around the code a bit. This is what I found:
-- begin --
diff dovecot-1.0.beta8/src/auth/passdb-vpopmail.c dovecot-1.0.beta3/src/auth/passdb-vpopmail.c 18a19,22
#ifndef HAVE_VPOPMAIL_OPEN_SMTP_RELAY #define HAVE_VPOPMAIL_OPEN_SMTP_RELAY #endif
-- end --
Looking at the code in dovecot-1.0.beta8/src/auth/passdb-vpopmail.c, I see that HAVE_VPOPMAIL_OPEN_SMTP_RELAY need to be defined for open_smtp_relay() from Vpopmail library to be called. This was easily fixed by:
-- begin --
./configure --prefix=/usr/local/dovecot-1.0.beta8 CFLAGS="-DHAVE_VPOPMAIL_OPEN_SMTP_RELAY"
-- end --
I hope someone else who may face a similar problem would find this useful.
Ken
C J Kenneth Tan, PhD OptimaNumerics Ltd Telephone: +44 798 941 7838 E-mail: cjtan@OptimaNumerics.com Telephone: +44 207 099 4428 Web: http://www.OptimaNumerics.com Facsimile: +44 207 100 4572
On Mon, 2006-06-05 at 23:26 +0000, C J Kenneth Tan -- OptimaNumerics Logically, it didn't sound to me that DRAC nor the info on the Wiki
which relies on log file parsing would apply/solve the problem. So I decided that I will roll up my sleeves and dig around the code a bit. This is what I found:
-- begin --
diff dovecot-1.0.beta8/src/auth/passdb-vpopmail.c dovecot-1.0.beta3/src/auth/passdb-vpopmail.c 18a19,22
#ifndef HAVE_VPOPMAIL_OPEN_SMTP_RELAY #define HAVE_VPOPMAIL_OPEN_SMTP_RELAY #endif
No such code has ever been in official Dovecot release. Maybe you had some patched beta3 sources?
On Mon, 2006-06-05 at 20:28 +0000, C J Kenneth Tan -- OptimaNumerics wrote:
Your criticism of qmail is off-topic for this list, and quite besides the point of the original posters question, which I will restate below without mention of qmail:
In any case, given the circumstances and the timescales, qmail is an "unmovable" item at this point in time.
You don't have to remove qmail - just add a mailer that does authentication somewhere as a relay for the roaming laptops (some mailer that has been updated in this century...). Or get gmail accounts for them and use their smtp auth forwarding if you can't do it yourself.
-- Les Mikesell lesmikesell@gmail.com
Matthias,
On 2006-06-05 18:05 +0200 Matthias Andree (matthias.andree@gmx.de) wrote:
C J Kenneth Tan -- OptimaNumerics <cjtan@OptimaNumerics.com> writes:
The current setup:
- Pine configured to send mail via localhost (qmail)
- qmail on localhost send mail to SMTP server
- SMTP server allow/reject connections based on POP-before-SMTP
- SMTP server performs spam and virus checks
qmail with vpopmail's POP-before-SMTP is actually much less setup work because it works right out of the box.
Because that's the only thing the decrepit qmail handles. Any modern MTA has evolved quite far from that point. No matter if you prefer Postfix, Exim, Courier, Sendmail or something else but qmail...
Is this going to be a case of replacing the MTA just because something changed in the POP/IMAP server?
Unfortunately, we have a number of things in our environment that prevents us from making such changes, especially given the timescales.
Ken
C J Kenneth Tan, PhD OptimaNumerics Ltd Telephone: +44 798 941 7838 E-mail: cjtan@OptimaNumerics.com Telephone: +44 207 099 4428 Web: http://www.OptimaNumerics.com Facsimile: +44 207 100 4572
On 2006-06-04 17:28:36 +0000, C J Kenneth Tan -- OptimaNumerics wrote:
I see the argument. The objective here is to allow relay by Linux laptops running qmail which receive mail from Pine running on the laptops. SMTP server would have SMTP level virus and spam check to counter this problem.
msmtp. you can teach pine to use that instead of the /usr/(lib|bin)/sendmail binary. it handles that problem nicely for you.
otherwise mtas like postfix can talk smtp auth to other mail servers aswell. [1] [2] [3] Even Qmail can do it some how: http://www.fehcom.de/qmail/smtpauth.html
darix
[0] http://msmtp.sourceforge.net [1] http://www.postfix.org/SASL_README.html#client_sasl [2] http://www.exim.org/exim-html-4.62/doc/html/spec_html/ch33.html#id2656623 [3] http://www.sendmail.org/doc/sendmail-current/cf/README search for: Providing SMTP AUTH Data when sendmail acts as Client (do they know about html already?)
-- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
Marcus,
This is getting off-topic, but just to reply to your suggestions:
On 2006-06-04 20:30 +0200 Marcus Rueckert (rueckert@informatik.uni-rostock....:
On 2006-06-04 17:28:36 +0000, C J Kenneth Tan -- OptimaNumerics wrote:
I see the argument. The objective here is to allow relay by Linux laptops running qmail which receive mail from Pine running on the laptops. SMTP server would have SMTP level virus and spam check to counter this problem.
msmtp. you can teach pine to use that instead of the /usr/(lib|bin)/sendmail binary. it handles that problem nicely for you.
Thanks for the suggestions. I'll look into it.
otherwise mtas like postfix can talk smtp auth to other mail servers aswell. [1] [2] [3] Even Qmail can do it some how: http://www.fehcom.de/qmail/smtpauth.html
I can get qmail-smtpd to do SMTP AUTH, patching against qmail-1.03. I can also get qmail-remote to do SMTP AUTH, patching against qmail-1.03. But I am having trouble getting them to work with qmail-1.03 plus all the other patches that I want.
But like I said, this is getting off-topic. My original post was about vpopmail authentication to get POP-before-SMTP changed between Dovecot 1.0.beta3 and 1.0.beta8.
Thanks!
Ken
C J Kenneth Tan, PhD OptimaNumerics Ltd Telephone: +44 798 941 7838 E-mail: cjtan@OptimaNumerics.com Telephone: +44 207 099 4428 Web: http://www.OptimaNumerics.com Facsimile: +44 207 100 4572
On 2006-06-05 19:29:35 +0000, C J Kenneth Tan -- OptimaNumerics wrote:
This is getting off-topic, but just to reply to your suggestions:
On 2006-06-04 20:30 +0200 Marcus Rueckert (rueckert@informatik.uni-rostock....:
On 2006-06-04 17:28:36 +0000, C J Kenneth Tan -- OptimaNumerics wrote:
I see the argument. The objective here is to allow relay by Linux laptops running qmail which receive mail from Pine running on the laptops. SMTP server would have SMTP level virus and spam check to counter this problem.
msmtp. you can teach pine to use that instead of the /usr/(lib|bin)/sendmail binary. it handles that problem nicely for you.
Thanks for the suggestions. I'll look into it.
otherwise mtas like postfix can talk smtp auth to other mail servers aswell. [1] [2] [3] Even Qmail can do it some how: http://www.fehcom.de/qmail/smtpauth.html
I can get qmail-smtpd to do SMTP AUTH, patching against qmail-1.03. I can also get qmail-remote to do SMTP AUTH, patching against qmail-1.03. But I am having trouble getting them to work with qmail-1.03 plus all the other patches that I want.
But like I said, this is getting off-topic. My original post was about vpopmail authentication to get POP-before-SMTP changed between Dovecot 1.0.beta3 and 1.0.beta8.
maybe look for an MTA that doesnt need so much patching? postfix is a pretty nice alternative.
darix
-- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
Marcus,
On 2006-06-05 22:41 +0200 Marcus Rueckert (rueckert@informatik.uni-rostock....:
On 2006-06-05 19:29:35 +0000, C J Kenneth Tan -- OptimaNumerics wrote:
On 2006-06-04 20:30 +0200 Marcus Rueckert (rueckert@informatik.uni-rostock....:
On 2006-06-04 17:28:36 +0000, C J Kenneth Tan -- OptimaNumerics wrote:
I see the argument. The objective here is to allow relay by Linux laptops running qmail which receive mail from Pine running on the laptops. SMTP server would have SMTP level virus and spam check to counter this problem.
msmtp. you can teach pine to use that instead of the /usr/(lib|bin)/sendmail binary. it handles that problem nicely for you.
Thanks for the suggestions. I'll look into it.
otherwise mtas like postfix can talk smtp auth to other mail servers aswell. [1] [2] [3] Even Qmail can do it some how: http://www.fehcom.de/qmail/smtpauth.html
I can get qmail-smtpd to do SMTP AUTH, patching against qmail-1.03. I can also get qmail-remote to do SMTP AUTH, patching against qmail-1.03. But I am having trouble getting them to work with qmail-1.03 plus all the other patches that I want.
But like I said, this is getting off-topic. My original post was about vpopmail authentication to get POP-before-SMTP changed between Dovecot 1.0.beta3 and 1.0.beta8.
maybe look for an MTA that doesnt need so much patching? postfix is a pretty nice alternative.
Thanks for the suggestion.
Ken
C J Kenneth Tan, PhD OptimaNumerics Ltd Telephone: +44 798 941 7838 E-mail: cjtan@OptimaNumerics.com Telephone: +44 207 099 4428 Web: http://www.OptimaNumerics.com Facsimile: +44 207 100 4572
C J Kenneth Tan -- OptimaNumerics <cjtan@OptimaNumerics.com> writes:
I see the argument. The objective here is to allow relay by Linux laptops running qmail
Not a good idea. <http://home.pages.de/~mandree/qmail-bugs.html>
which receive mail from Pine running on the laptops. SMTP server would have SMTP level virus and spam check to counter this problem.
Euh, "alleviate" the problem at best. Virus scanners only work against known viruses. The gap between a new one and your virus scanner being updated can be several days too long for SMTP... the problem starts as the first Windows laptop joins your network, and by then, the POP-before-SMTP problem will be forgotten.
-- Matthias Andree
Matthias,
On 2006-06-05 18:04 +0200 Matthias Andree (matthias.andree@gmx.de) wrote:
C J Kenneth Tan -- OptimaNumerics <cjtan@OptimaNumerics.com> writes:
I see the argument. The objective here is to allow relay by Linux laptops running qmail
Not a good idea. <http://home.pages.de/~mandree/qmail-bugs.html>
What is not a good idea? Allowing relay? Linux laptops? qmail? If qmail is not a good idea, then unfortunately this is an "unmovable" item. We have a number of things in our environment that prevents us from making such changes, especially given the timescales.
which receive mail from Pine running on the laptops. SMTP server would have SMTP level virus and spam check to counter this problem.
Euh, "alleviate" the problem at best. Virus scanners only work against known viruses. The gap between a new one and your virus scanner being updated can be several days too long for SMTP... the problem starts as the first Windows laptop joins your network, and by then, the POP-before-SMTP problem will be forgotten.
I understand the argument. The environment that we are talking about here consists of Linux laptops, which I have mentioned before, and OpenBSD and Linux mail hosts. Also, while I understand that past performance is no indication of future response times, ClamAV and F-Prot seem to have fairly prompt response.
Correct me if I am wrong, but this seem to have little to do with the fact that vpopmail authentication to enable POP-before-SMTP in Dovecot 1.0.beta3 and 1.0.beta8 changed.
Ken
C J Kenneth Tan, PhD OptimaNumerics Ltd Telephone: +44 798 941 7838 E-mail: cjtan@OptimaNumerics.com Telephone: +44 207 099 4428 Web: http://www.OptimaNumerics.com Facsimile: +44 207 100 4572
On Sun, 04 Jun 2006, C J Kenneth Tan wrote:
Thanks for the pointer. I see that you put on the Wiki claiming that SMTP AUTH is the alternative.
Indeed.
For the rest of this message, assume "DRAC", "POP-before-SMTP", "IMAP-before-SMTP", "SMTP-before-POP" and "SMTP-before-IMAP" to be mutually synonymous. These are one specific implementation (DRAC) and four names for the same scheme.
I was reporting that using 1.0.beta8, vpopmail's pop-before-smtp functionality stopped working. Is intentional?
I don't know if it was intended by the person making the change. I have never used vpopmail in production, and I don't like the vpopmail scheme that is wedded to the buggy qmail.
I didn't see any relevant changes in the ChangeLog file.
- Would you be able to explain to me how SMTP AUTH prevents virus relay that cannot be accomplished with POP-before-SMTP?
POP-before-SMTP "authenticates" an IP address (and behind NAT, perhaps a whole LAN) for relay for a given time span, anything between a few and 60 minutes, regardless of what's behind the IP address. In dynamic IP environments (DHCP, PPP dial-up), reassigned IPs may authenticate the next site/user to get your IP.
SMTP AUTH authenticates only a single TCP connection made by a single user for relay through the very same TCP connection, thus, effectively, a single users's single application's "send mail" operation.
A - With dynamic DNS, the DRAC server does not know that the client has gone away and been replaced by another, possibly infested, server, and permits relay to them.
B - Also, if using several machines behind a NAT or masquerading router (possibly WLAN without WPA2 -- many ship with "open" or "WEP" networks), the whole LAN is authenticated for the given time. If there are untrusted users, they can wreak havoc and shift the blame on you.
C - Only important for shell hosts with many users, one user authenticating on a given host also gives implicit relay permission to all other (possibly hundreds of) users on the same host. Again, malicious users can foist the blame upon you.
Note that A, B and C use YOUR credentials, so unless you can prove you lost the IP and which IP address you got, you're liable for all abuse.
SMTP AUTH authenticates a single end-to-end TCP connection, the same through which the messages are relayed. If the connection is terminated properly (all messages sent), times out, the client changes IP, whatever, the relay permit ends. It doesn't apply to other users on your computer, other applications that you run, other computers in your NATed LAN, or the next dialup user to get your former IP address assigned.
All in all, DRAC is only useful for a completely trusted LAN in a family or similar, when the authenticating host has a static IP. In such situation, DRAC isn't needed for static IP but can just allow relay to the static IP.
Thus, DRAC is dangerous in scenarious where it could be useful, and useless in scenarios where it could be used safely.
To make a long story short: DRAC and other POP-before-SMTP or SMTP-after-POP schemes should be prohibited and stipulated in the Penal Code.
- Would you be able to also explain what do you mean by "dangerous"?
- Would you be able to also explain what do you mean by "major security risk"?
These are inseparable. "Dangerous" or "security risk" means that you are giving relay permission to people you don't know or you don't trust or you otherwise do not mean to give relay permission, and one malicious user or innocently infected machine can spam viruses/phishing/whatever on your account.
I have received messages off-list (hence I cannot reveal sustaintable identifying information to substantiate this claim, you'll probably - given you know how to work scientificially - ignore this rather than take my word for it) confirming virus incidents in SMTP-after-POP schemes.
If you have an outbound router running Postfix or Exim, either is capable of authenticating depending on sender's address (for Postfix, you need a recent 2.3 snapshot - I'm running such a version and it works well for me in production).
HTH,
-- Matthias Andree
On Sun, 2006-06-04 at 20:52 +0200, Matthias Andree wrote:
For the rest of this message, assume "DRAC", "POP-before-SMTP", "IMAP-before-SMTP", "SMTP-before-POP" and "SMTP-before-IMAP" to be mutually synonymous. These are one specific implementation (DRAC) and four names for the same scheme.
I think you meant "SMTP-after-POP" and "SMTP-after-IMAP" since "SMTP-before-POP" and "SMTP-before-IMAP" make no sense at all.
-- Luca Corti PGP Key ID 1F38C091 BOFH excuse of the moment: We'll fix that in the next (upgrade, update, patch release, service pack).
On Mon, 05 Jun 2006, Luca Corti wrote:
On Sun, 2006-06-04 at 20:52 +0200, Matthias Andree wrote:
For the rest of this message, assume "DRAC", "POP-before-SMTP", "IMAP-before-SMTP", "SMTP-before-POP" and "SMTP-before-IMAP" to be mutually synonymous. These are one specific implementation (DRAC) and four names for the same scheme.
I think you meant "SMTP-after-POP" and "SMTP-after-IMAP" since "SMTP-before-POP" and "SMTP-before-IMAP" make no sense at all.
Right, thanks. Sorry for the confusion.
-- Matthias Andree
participants (8)
-
C J Kenneth Tan -- OptimaNumerics
-
John Peacock
-
Les Mikesell
-
Luca Corti
-
Magnus Holmgren
-
Marcus Rueckert
-
Matthias Andree
-
Timo Sirainen