Re: My OpenBSD 5.0 installation experience (long rant)
Dmitrij D. Czarkoff czark...@gmail.com writes: So you state that the fact that if one chooses to use the whole disk, the whole disk is used needs further documentation? Once upon a time, mkfs used to make a 10-second pause before starting. That's the way you do it. -- Fredrik Stax\ang | rot13: s...@hcqngr.hh.fr This is all you need to know about vi: ESC : q ! RET
Re: My OpenBSD 5.0 installation experience (long rant)
Dmitrij D. Czarkoff czark...@gmail.com writes: On Mon, 2012-03-12 at 08:55 +0100, Fredrik Staxeng wrote: Dmitrij D. Czarkoff czark...@gmail.com writes: So you state that the fact that if one chooses to use the whole disk, the whole disk is used needs further documentation? Once upon a time, mkfs used to make a 10-second pause before starting. That's the way you do it. That is an answer to the question How? (actually a bad one, as if the user didn't read messages before hitting [Enter], he probably won't do it after doing so), while my statement implied more of Why? you didn't address at all. I jumped into the middle here, I know. I think the 10-second delay is a brilliant solution. Much better than an are you sure? question. I think that there is a large probability that the user will spend that time reading the message, and consider whether he really wants to do it. -- Fredrik Stax\ang | rot13: s...@hcqngr.hh.fr This is all you need to know about vi: ESC : q ! RET
Snappy Answers to Stupid Questions - WTF?
Do you want users at all? Or was Linus right? -- Fredrik Stax\ang | rot13: s...@hcqngr.hh.fr This is all you need to know about vi: ESC : q ! RET
Re: Relaying denied. Trying to do TLS+SMTP AUTH. Do I really need SASL?
Lyndon Nerenberg [EMAIL PROTECTED] writes: Well, that is exactly what I want to do. I use the system passwords for imap anyway, so why not? Of course, the channel must be protected by SSL/TLS when you do that. Because there are a large number of IMAP clients that are not aware of LOGINDISABLED, and which will blindly attempt LOGIN or AUTH PLAIN in the absence of TLS (which they are not aware of, either). Many IMAP clients predate RFC3501. So those passwords (with the matching authentication ids) are going to be flying around the Internet in the clear no matter what you do. Using the UNIX account password for IMAP (or POP) in this manner makes your system effectively password free. You have a way with words, but I think you are exaggerating slighly. I have never allowed plaintext IMAP/POP. Wouldn't dream of it. The client is Thunderbird. The default IMAP configuration will use plaintext passwords, but only if it talks to an IMAP server that does not support TLS, but see above. Also, I always use imaps/993, and not TLS on 143. I don't fell comfortable using a password over a connection that is encrypted, if possible. But I must thank you for reminding me to disable port 143, -- Fredrik Stax\ang | rot13: [EMAIL PROTECTED] This is all you need to know about vi: ESC : q ! RET
Relaying denied. Trying to do TLS+SMTP AUTH. Do I really need SASL?
I have a server that runs OpenBSD 4.1, and a laptop running Windows. I want to use Thunderbird on the laptop to send mail via the server. The laptop connects from many different networks. I would like to use port 587, since some isps blocks port 25. I want to use my username/password to authenticate. I want to use TLS to protect the password. I get the dreaded 'Relaying denied. Proper authentication needed.' The relevant parts of the mc file looks like this dnl dnl TLS/SSL support; uncomment and read starttls(8) to use. dnl define(`CERT_DIR', `/etc/ssl')dnl define(`confCACERT_PATH', `CERT_DIR')dnl define(`confCACERT', `CERT_DIR/CAcert.pem')dnl define(`confSERVER_CERT', `CERT_DIR/sendmailcert.pem')dnl define(`confSERVER_KEY', `CERT_DIR/private/sendmail.pem')dnl define(`confCLIENT_CERT', `CERT_DIR/sendmailcert.pem')dnl define(`confCLIENT_KEY', `CERT_DIR/private/sendmail.pem')dnl dnl SMTP AUTH define(`confAUTH_MECHANISMS', `PLAIN LOGIN')dnl TRUST_AUTH_MECH(`PLAIN LOGIN')dnl define(`confAUTH_OPTIONS', `A p')dnl Googling gives a lot of references to SASL. Do I really have to go down that road to do something as simple as this? -- Fredrik Stax\ang | rot13: [EMAIL PROTECTED] This is all you need to know about vi: ESC : q ! RET
Re: Relaying denied. Trying to do TLS+SMTP AUTH. Do I really need SASL?
Stuart Henderson [EMAIL PROTECTED] writes: On 2007/06/30 12:46, Fredrik Staxeng wrote: Googling gives a lot of references to SASL. Do I really have to go down that road to do something as simple as this? for smtp auth, yes. OK. but for a simple use like this, why not just ssh-tunnel instead? Two answers: a) Thunderbird does not support that natively, so that means more complex setup on the client side. (Especially since the client runs Windows). b) I like using the standard way whenever that is adequate. All of the mail clients my mother might have heard of supports port 587/tls/auth. On 4.0 I used the postfix-sasl package. But you see, I am really impessed by OpenBSD's proudest boast Only two remote holes in the default install, in more than 10 years!. But that caveat, in the default install, excludes the packages. And you only need one vulnerability to get exploited. So get the full benefit of the excellent security work of the OpenBSD developers, I should not really have any code from packages in the network services, either directly (postfix) or indirectly (cyrus-sasl). Unfortunately, the default install does not support imap, so I need at least one package anyway. I would like to avoid cyrus-sasl if possible though, since that is way more complexity than I need. I'll look through packages and try to find something that fits. -- Fredrik Stax\ang | rot13: [EMAIL PROTECTED] This is all you need to know about vi: ESC : q ! RET
Re: Relaying denied. Trying to do TLS+SMTP AUTH. Do I really need SASL?
Claus Assmann [EMAIL PROTECTED] writes:
On Sat, Jun 30, 2007, Fredrik Staxeng wrote:
I get the dreaded 'Relaying denied. Proper authentication needed.'
You don't need AUTH, STARTTLS is sufficient. See cf/README:
Relaying
SMTP STARTTLS can allow relaying for remote SMTP clients which have
successfully authenticated themselves. If the verification of the cert
failed (${verify} != OK), relaying is subject to the usual rules.
Otherwise the DN of the issuer is looked up in the access map using the
tag CERTISSUER. If the resulting value is RELAY, relaying is allowed.
If it is SUBJECT, the DN of the cert subject is looked up next in the
access map using the tag CERTSUBJECT. If the value is RELAY, relaying
is allowed.
Then I would need client certificates, wouldn't I?
--
Fredrik Stax\ang | rot13: [EMAIL PROTECTED]
This is all you need to know about vi: ESC : q ! RET
Re: Relaying denied. Trying to do TLS+SMTP AUTH. Do I really need SASL?
Claus Assmann [EMAIL PROTECTED] writes: On Sat, Jun 30, 2007, Fredrik Staxeng wrote: Claus Assmann [EMAIL PROTECTED] writes: I get the dreaded 'Relaying denied. Proper authentication needed.' You don't need AUTH, STARTTLS is sufficient. See cf/README: Then I would need client certificates, wouldn't I? Yes. As you have a cert for your server, why not create one for your client? It's barely more complicated than exchanging the credentials for AUTH, but STARTTLS is much simpler to set up than AUTH (i.e., Cyrus-SASL). I have a self-signed server cert that I created using commands that I barely understand. I have no idea where to start. I guess I need a CA key, and CA cert. Then I need to make sendmail trust the new cert? Then I can generate a key, signing request, and certificate, and make a PKCS12 file, which seems to be what Thunderbird wants. Would it be something like this: openssl dsaparam 1024 -out dsa1024.pem openssl gendsa -out client.key dsa1024.pem openssl req -new -key client.key -out client.csr openssl x509 -req -days 365 -in client.csr -signkey /etc/ssl/private/sendmail.pme -out client.crt openssl pkcs12 -export -in client.crt -inkey client.key -out client.p12 -- Fredrik Stax\ang | rot13: [EMAIL PROTECTED] This is all you need to know about vi: ESC : q ! RET
Re: Relaying denied. Trying to do TLS+SMTP AUTH. Do I really need SASL?
Claus Assmann [EMAIL PROTECTED] writes: On Sat, Jun 30, 2007, Fredrik Staxeng wrote: I have a self-signed server cert that I created using commands that I barely understand. I have no idea where to start. By reading the fine instructions :-) man starttls I have read that, done that. Nothing about client certs there. sendmail operations guide: doc/op/op.* Section 6.6? Nor there. Earlier you wrote: Yes. As you have a cert for your server, why not create one for your client? It's barely more complicated than exchanging the credentials for AUTH, but STARTTLS is much simpler to set up than AUTH (i.e., Cyrus-SASL). I am not optimistic that it will be as simple as that implies. I have tried to understand x509 and openssl before. Anyway, you are the maintainer of the free version of sendmail? Would you consider putting in LOGIN/PLAIN support without SASL? It would improve the functionality of the OpenBSD default install. -- Fredrik Stax\ang | rot13: [EMAIL PROTECTED] This is all you need to know about vi: ESC : q ! RET
Re: Relaying denied. Trying to do TLS+SMTP AUTH. Do I really need SASL?
Claus Assmann [EMAIL PROTECTED] writes: On Sat, Jun 30, 2007, Fredrik Staxeng wrote: man starttls I have read that, done that. Nothing about client certs there. sendmail doesn't care as long as it is a cert. Surely it has to be signed with some key trusted by the particular sendmail server? Anyway, you are the maintainer of the free version of sendmail? Yes. Would you consider putting in LOGIN/PLAIN support without SASL? If someone sends a good patch: yes (see the website for the correct address where to sent patches). Note that this isn't as simple as it might seem: the problem is where you store the passwords for PLAIN. You certainly don't want to reuse the existing system passwords. Well, that is exactly what I want to do. I use the system passwords for imap anyway, so why not? Of course, the channel must be protected by SSL/TLS when you do that. -- Fredrik Stax\ang | rot13: [EMAIL PROTECTED] This is all you need to know about vi: ESC : q ! RET
