Re: The most secure POP server
"Brett Randall" [EMAIL PROTECTED] writes: Ok, here's the deal: qmail-pop3d is NOT secure, nor are most other standard POP3 daemons. POP passwords are sent in cleartext and are not encrypted. They can be viewed by people snooping a connection (although this is not as easy as it sounds). A way of fixing this insecurity is to use SSL, [...] As long as you're only concerned about the password and not about the security of the message content itself you can also do APOP, but this is an issue with checkpassword and not qmail-pop3d itself. Many of our users, including myself, prefer APOP. If I want a secure message body I use PGP. -t
Re: forwarding without .forward package?
"Voitenko, Denis" [EMAIL PROTECTED] writes: I have a machine that accepts mail for domain.com and has a user denis on it. I'd like to forward all the mail to [EMAIL PROTECTED] to a different email. I tried to create a /var/qmail/alias/.qmail-denis which contained the destination email. Yet, qmail still delivers messages to the local mailbox. Is there a way to do this without installing the .forward package? If a UNIX account 'denis' exists and you don't make special arrangements for 'denis' in users/assign then ~alias is not consulted at all. Try echo '[EMAIL PROTECTED]' ~denis/.qmail instead. -t
Re: Store + forward email
"Stuart Harris" [EMAIL PROTECTED] writes: 1, can you selectively process mail for a specific domain? Deliver it all to one Maildir and use serialmail 2, is there any way to increase the maximum queue time, obviously because this mail is stored indefinitely for the customer then we do NOT want it to bounce. This is not an issue 'cause the mail does not stay in the queue. 3, can you suggest any queue analysys applications other than qmail-qstat? No, sorry. -t
Re: Sendmail to qmail
Diego Alejandro Puertas Fernandez [EMAIL PROTECTED] writes: Thomas Neumann wrote: The downtime would amount to the time that is needed for folder conversion, during which I would disable SMTP services (or at least not have qmail-send running yet) to avoid a local delivery taking place to a folder that is currently being converted to a Maildir. You are not forced to use Maildir, you can still use mailbox, you can still use /var/spool/mail so the downtime is keept to a minimun. You *must* use Maildir format if you want to use qmail-pop3d, and you _really_ do want this. -t
Re: Any Decent IMAP server?
Philip Gabbert [EMAIL PROTECTED] writes: Does anybody have any suggestions on a good IMAP server? I've gotten courier-imap installed and running, but my IMAP clients (Netscape Communicator 4.7 on RedHat Linux and Outlook Express 5.0 on a Mac) are getting an error back from courier-imap: "Error in IMAP command received by server". This seems to be a generic error message that is used when any is sent wrong to the server. Did you strictly follow the hints given at URL:http://www.inter7.com/courierimap/README.imap.html on how to configure Netscape for IMAP? Works for me (modulo creating subfolders, but thats a Netscape bug). I've checked the logs, and no error messages in there. Yeah. Dig out an Ethernet packet sniffer (Ethereal or something) and have it display the entire IMAP session so you can see exactly what the client sends and how the server reacts to this. Anybody have a suggestion on another IMAP server, how a way to get courier-imap to work correctly? You can try Cyrus, 'though it uses its own mail storage format and it can not handle login names what have a dot in them, which makes it unusable for me, but YMMV. -t
Re: Any Decent IMAP server?
"Denis Voitenko" [EMAIL PROTECTED] writes: Try: http://www.davideous.com/imap-maildir/ The UW-IMAP server [...] That is correct. I've am using it for about a month now and am extremely happy with it. The LAN has 80 users on it and it hasn't come even close to crashing. I had some problems patching it but David put a patched version on the site upon my request. Thanks, David. Ok, so what is necessary to make this really useful in the following scenario : (a) Thousands of IMAP users spread accross hundreds of virtual domains all running under a single UNIX user-id and using custom authorization (i.e. not UNIX /etc/passwd or Kerberos but instead something like a CDB File, an SQL backend database etc.), with IMAP user-ids looking like 'user%dom.ain' (b) As a consequence of (a), there are no "real" home directories per user [in the sense of getpwuid(UID)-pw_dir], therefore the Maildirs are spread over some spool area that is based on whatever layout I find most efficient for the job. Can I do this without doing some Major Hacking [TM] to the code? -t
Re: Problem compiling courier-imap
Stefan Osterman [EMAIL PROTECTED] writes: I have problem compiling courier-IMAP on Solaris 2.6 checking for wait... yes checking for wait3... yes checking for sigblock... no checking if wait function is broken... yes configure: error: I give up -- neither wait nor wait3 works properly configure: error: ./configure failed for waitlib You could try to configure '--with-waitfunc=wait3' to force it; maybe it works anyway, but watch out for zombie processes once you have imapd running. To get this far I also had to set "without-random" Sometimes Solaris can suck a golf ball through a pipe ... -t
Re: Sendmail to qmail
"Tyler J. Frederick" [EMAIL PROTECTED] writes: I have a client that has a box with 5000 users on it running sendmail and popper. They are hosting email on here for approx 100 virtual domains and they are parsing it with the sendmail /etc/virtusertable. They want to migrate to a new server and I'd like to put them on qmail. I was thinking a qmail/vpopmail/mysql solution would be the best and easiest to administer, but I could be wrong. Keep in mind that these 5000 users all have their mail clients all setup for the current system (Using their 8 char unix username and passwd) and my client doesn't want to have to make all of them change their settings to the user%domain.com. If they use their UNIX username/password right now, this means their usernames are unique over all virtual domains anyway right now, not just unique within each virtual domain, right? Then it should be no problem to set up a one-to-one mapping from unique, unqualified username to the user's virtual maildomain (perhaps using a CDB file that is re-generated once a day for the mapping) and implement a checkpassword for qmail-pop3d that uses this mapping to direct the user to his associated Maildir. Sounds like 30 lines of perl and be done. For mass-converting all currently existing folders to Maildir format I'd suggest a small shell script that uses formail (from procmail) and safecat ( see URL:http://www.nb.net/~lbudney/linux/software/safecat.html ) The downtime would amount to the time that is needed for folder conversion, during which I would disable SMTP services (or at least not have qmail-send running yet) to avoid a local delivery taking place to a folder that is currently being converted to a Maildir. -t
Re: rejecting mail for 1 user
"Tim Hunter" [EMAIL PROTECTED] writes: This is something that has been bugging me for quite awhile but never had the time to deal with it. Apparently some time ago before I became the email admin for our domain the address [EMAIL PROTECTED] became a target for many a spammer. Now this account does not exist and is very doubtful that it ever existed. echo /dev/null ~alias/.qmail-annie:loul If cimx.com is a virtual domain you'd have to replace ~alias with the controlling directory for that domain, of course. -t
Re: methods for ETRN
Sam [EMAIL PROTECTED] writes: On 26 Oct 1999, Chris Shenton wrote: At the very least, there is a port of Perl to Win32, and it would be rather trivial to write a POP3 client in Perl. In fact, I'd bet that if I look I'll find both a Perl POP3 module and a Perl SMTP module, so it would be a rather trivial excersize to use both to download mail via POP3, and dump into into MSexchange via SMTP. I've written a tiny Perl5 program that does exactly this. It's available from URL:http://home.tmr-online.de/tn/getpop.pl and should work under Win32 provided that all required modules can be installed. -t
Re: M$ Exchange - qmail
Dave Sill [EMAIL PROTECTED] writes: Thomas Neumann [EMAIL PROTECTED] wrote: I think Exchange can also use ETRN to tell another SMTP server that it wants it to send queued mail, but ETRN is even worse, being incredibly insecure Not true. TURN is incredibly insecure, because it feeds messages back over an unverified connection, but ETRN is as secure any other SMTP exchange. Yes, exactly as secure as any other SMTP command, which is a nice way to say 'not secure at all'. ETRN, on servers that support it, is part of a normal, unverified SMTP session. What verification capabilities do you see in ETRN as defined in RFC1985? It would at least be pseudo-secure if the domain name given as parameter of the ETRN command would be the FQDN to connect to for sending the queues content and the ETRN capable MTA on the server side would open a separate connection to that given host, but this is not the case (and can not be, as RFC1985 section 5 says the given domain is allowed to resolve to only an MX, hence is allowed to lack an A record and therefore maybe can not be connect()'ed to). The domain supplied with ETRN is only to tell the server which elements of its queue it should send to the client. Basically, it's just telling a server "hey, if you've got any mail for host X, you should try sending it now". Yes, and it will send it over the already running SMTP session in which the ETRN command was issued. So what keeps me away from telnet'ing to some SMTP server that I know does ETRN for domain foo.bar.com and shoot a 'ETRN foo.bar.com' at it and it will happily send me all of foo.bar.com's mails? qmail+serialmail supports AutoTURN, which is like ETRN, but doesn't require the remote site to send an ETRN command. This is true, but it only works iff your dialup clients have static IP addresses. -t
Re: M$ Exchange - qmail
"Petr Novotny" [EMAIL PROTECTED] writes: This is true, but it only works iff your dialup clients have static IP addresses. No; with a moderate amount of hacking (aren't there scripts on www.qmail.org) you can kick SMTP after verifying some shared secret - like POP3 password. Yes, of course, and I've already written such a program that is in use on our server, based on a shared MD5-encoded secret just like APOP. All I meant to say is that serialmail and the AutoTURN mechanism as shipped and as documented in the distribution by DJB himself relies on static IP addresses for security. Nobody keeps you away from spicing it up with some homegrown add-ons, just like I (and I guess you as well) have done. And now the circle closes and we are just where we started. The required 'moderate amount of hacking to kick of SMTP' can be avoided by use of a POP3-based fetchmail-like tool on the M$-Exchange machine that stuffs each mail into Exchange's SMTP server after it got it via POP3. This combines the already existing password security offered by POP3 (preferrably APOP) with the advantage of not having to 'kick SMTP' on the qmail machine. That was my point from the start and that's why I suggested the POP3-ish way of doing it. A further advantage is that a homegrown custom way of verifying a shared secret and kicking SMTP will most likely be non-standard (because of its home-grown nature) while you can stay safe in RFC-land if you go the POP3 route. -t
Re: M$ Exchange - qmail
"Olivier M." [EMAIL PROTECTED] writes: I guess that an Exchange server don't simply use STMP to communicate with another exchange server. What kind of protocol is it, and is it possible to emulate it using qmail tools ? I looked on the qmail homepage and in some other places, and didn't found much details about that : maybe you know a little bit more ? I'm just looking for some more docs (url...) and why not qmail/exchange configuration examples. I'm not an expert on M$ Exchange by any means, but I know for sure that Exchange can run an SMTP server for itself, and this is where you can hook up to. Just have all customer mail delivered into Maildirs on your new qmail machine (one Maildir per customer), then you can use a small program to fetch the mail using POP3 from the qmail machine to the Windows machines running Exchange, where you re-inject them into the local SMTP server offered by Exchange. I do the same for a bunch of customers running Lotus Notes SMTP servers behind dialup lines. I think Exchange can also use ETRN to tell another SMTP server that it wants it to send queued mail, but ETRN is even worse, being incredibly insecure and qmail doesn't support it w/o a patch anyway, so stay away from it. -t
Re: M$ Exchange - qmail
"Olivier M." [EMAIL PROTECTED] writes: On Sun, Aug 01, 1999 at 11:47:27PM +0200, Thomas Neumann wrote: I'm not an expert on M$ Exchange by any means, but I know for sure that Exchange can run an SMTP server for itself, and this is where you can hook up to. Just have all customer mail delivered into Maildirs on your new qmail machine (one Maildir per customer), then you can use a small program to fetch the mail using POP3 from the qmail machine to the Windows machines running Exchange, where you re-inject them into the local SMTP server offered by Exchange. I do the One maildir per user or per domain ? If it is per domain, then it should be possible to use serialmail to send the mails from the linux server to the NT client: it's good documented. Per (customer-) domain. You need to find a method to trigger serialmail on the qmail server once the Exchange machine is logged in, and this needs to be secure (password protected or whatever). All in all this will not be easier than the POP3 solution I outlined. -t
Re: Authenticating qmail towards a SQL data base
Ignacio de Cordoba [EMAIL PROTECTED] writes:
Anybody has any ideas on how to modify qmail-getpw and make it check
users on a different way other than /etc/passwd ? (PostgreSQL)
It is easy to write a checkpassword replacement that does
whatever authentification you can imagine. We also have
our customer data in a PostgreSQL database, but we deliberately
chose not to checkpassword() directly against the SQL database
because if you do that then the database server becomes a
potential single point of failure (PostgreSQL machine goes
down - Users can't get mail via POP3 - Hotline jumps
straight into panic! mode - you lose)
Because of that we generate a per-customer-domain CDB
database from the data that is stored in the SQL database
once per hour. With that scheme even if the PostgreSQL server
goes down existing users still can get at their mail (you
just can't update/add users for as long as the SQL server
is down, but that's more acceptable).
Attached below is our checkpassword replacement that works
like explained above. It expects to find a passwd.cdb for
each customer domain in /MailSpool/$customer_domain/
and clients need to use username%domain as their POP3
login id.
#!/usr/bin/perl -wT
#
# $Id$
#
use strict;
sub read_parms {
my $buf = 512 x 0;
local *INP;
open(INP, "=3") || die "can't open fd 3: $!\n";
sysread(INP,$buf,512) || die "sysread failed: $!\n";
close(INP);
$buf =~ /([^\0]+)\0([^\0]+)\0([^\0]+)\0/;
}
sub checkpass {
my($u,$p,$s) = @_;
if (defined($u) defined($p) defined($s)) {
if ($u =~ /(\S+)[@%](\S+)/) {
my($usr,$dom) = ($1,$2);
chdir "/MailSpool/$dom" || exit 111;
if (-d $usr -d "$usr/Maildir" -f 'passwd.cdb') {
use CDB_File;
my %db;
tie %db, 'CDB_File', 'passwd.cdb' || exit 111;
my $dbpass = $db{$usr};
untie(%db);
# prepare environment in case we succeed below
$ENV{'PATH'} = '/admin/qmail/bin:/bin:/usr/bin';
$ENV{'HOME'} = "/MailSpool/$dom/$usr";
$ENV{'USER'} = $usr;
$ENV{'SHELL'} = '/bin/true';
my $ok;
$ok = defined($dbpass) $dbpass eq $p chdir($usr);
use IO::File;
my $logf = new IO::File "5";
if (defined($logf)) {
$logf-print(!$ok ? "FAILED: " : "", "User='$u' Pass='$p'
Stamp='$s'\n");
$logf-close;
}
return $ok;
}
}
}
return 0;
}
exec @ARGV if checkpass(read_parms());
exit 111;
Re: bcc fields
Chris Johnson [EMAIL PROTECTED] writes: When you say "with a qmail 1.03 smtp server for outgoing mail," do you mean that this message was injected with SMTP? If so, then qmail-inject never saw the message. qmail-smtpd doesn't look at the headers, and execs qmail-queue to queue the message as is. It's the responsibility of the software on the remote end to strip the Bcc field and turn it into SMTP "RCPT TO" commands. Uh... you say that a SMTP MTA should analyze message headers and turn the retrieved information into envelope recipient data? I don't buy that. How's that supposed to work anyway: The moment the first message header appears in a SMTP connection's data stream is by definition the DATA part of the session. At that time all envelope sender and recipient specifications have been completed anyway. The only scenario where a SMTP MTA must deduce envelope information from message headers is when the MTA is locally invoked a'la "sendmail -t". -t
Re: ETRN support on Qmail
On Mon, Jan 25, 1999 at 11:05:02AM +0200, Ãéþñãïò ÊïõëïãéÜííçò wrote: Qmail does not seem to support the ETRN function. Thus there is virtually no way for a remote SMTP dialup server to connect ot the net and emeediatelly request retrieval of the mails residing in the qmail queue for that server. Is there any fisible solution to the problem? Is there going to be ETRN support in future releases? I think there are ETRN patches on www.qmail.org, but I'd rather avoid ETRN because it sucks as far as security is concerned (ETRN does not allow sufficient authorization of the client that connects and requests to be sent the contents of a mail queue). There are alternative solutions that should give better results than ETRN. You might have a look at the "serialmail" package, also available via www.qmail.org. With serialmail installed on the qmail server you can deliver all mail for your wannebe ETRN customer into a Maildir and then have the contents of that Maildir be sent to the client via SMTP once he connects. This is usually what people with MS Exchange or Lotus Domino SMTP servers want and why they're asking for ETRN in the first place. The only thing you'll have to arrange for is that you need a mechanism for the client to "trigger" the serialmail process on the qmail server, and that mechanism can be written to offer sufficient security and it's easy to do. Another, maybe even easier solution is to deliver all mail for the ETRN customer into a Maildir like outlined in the previous solution but instead of using serialmail in the qmail server have the client use a program that retrieves to contents of his Maildir via POP3 and re-injects the mail into the clients local SMTP server -- basically a poor mans "fetchmail". -t
