Re: [exim] sending mail from outside

Página Principal
Apagar esta mensagem
Responder a esta mensagem
Autor: Tony Finch
Data:  
Para: Samuel Thoraval
CC: exim-users, dot
Assunto: Re: [exim] sending mail from outside
On Fri, 12 May 2006, Samuel Thoraval wrote:
>
> Thanks a lot but it doesn't help me much...


I'm thinking of adding the following to the default configuration file, to
make it easier for people to get basic authentication working:

--- configure.default    20 Feb 2006 16:31:49 -0000    1.7
+++ configure.default    12 May 2006 11:43:01 -0000
@@ -130,6 +130,48 @@
 # spamd_address = 127.0.0.1 783



+# If Exim is compiled with support for TLS, you may want to enable the
+# following options so that Exim allows clients to make encrypted
+# connections. In the authenticators section below, there are template
+# configurations for plaintext username/password authentication. This kind
+# of authentication is only safe when used within a TLS connection, so the
+# authenticators will only work if the following TLS settings are turned on
+# as well.
+
+# Allow any client to use TLS.
+
+# tls_advertise_hosts = *
+
+# Specify the location of the Exim server's TLS certificate and private key.
+# The private key must not be encrypted (password protected). You can put
+# the certificate and private key in the same file, in which case you only
+# need the first setting, or in separate files, in which case you need both
+# options.
+
+# tls_certificate = /etc/ssl/exim.crt
+# tls_privatekey = /etc/ssl/exim.pem
+
+# In order to support roaming users who wish to send email from anywhere,
+# you may want to make Exim listen on other ports as well as port 25, in
+# case these users need to send email from a network that blocks port 25.
+# The standard port for this purpose is port 587, the "message submission"
+# port. See RFC 4409 for details. Microsoft MUAs cannot be configured to
+# talk the message submission protocol correctly, so if you need to support
+# them you should also allow TLS-on-connect on the traditional but
+# non-standard port 465.
+
+# daemon_smtp_ports = 25 : 465 : 587
+# tls_on_connect_ports = 465
+
+# If you enable the two options above, you will probably want to define
+# specific ACLs for message submission, different from the general-purpose
+# port 25 ACL. The ACL hooks use string expansion, so you can use a setting
+# like:
+
+# acl_smtp_rcpt = ${if ={25}{$interface_port} \
+#                      {acl_check_rcpt} {acl_check_rcpt_submit} }
+
+
 # Specify the domain you want to be added to all unqualified addresses
 # here. An unqualified address is one that does not contain an "@" character
 # followed by a domain. For example, "caesar@???" is a fully qualified
@@ -662,10 +704,51 @@
 #                   AUTHENTICATION CONFIGURATION                     #
 ######################################################################


-# There are no authenticator specifications in this default configuration file.
+# The following authenticators support plaintext username/password
+# authentication using the standard PLAIN mechanism and the traditional but
+# non-standard LOGIN mechanism, with Exim acting as the server. PLAIN and
+# LOGIN are enough to support most MUA software.
+#
+# These authenticators are not complete: you need to change the
+# configuration to specify how passwords are verified. They are set up to
+# offer authentication to the client only if the connection is encrypted
+# with TLS, so you also need to add support for TLS. See the global
+# configuration options section at the start of this file for more about
+# TLS.
+#
+# The default RCPT ACL checks for successful authentication, and will accept
+# messages from authenticated users from anywhere on the Internet.

begin authenticators

+# PLAIN authentication has no server prompts. The client sends its
+# credentials in one lump, containing an authorization ID (which we do not
+# use), an authentication ID, and a password. The latter two appear as
+# $auth2 and $auth3 in the configuration and are checked against a valid
+# username and password. In a real configuration you would typically use
+# $auth2 as a lookup key, and compare $auth3 against the result of the
+# lookup, perhaps using the crypteq{}{} condition.
+
+#PLAIN:
+#  driver                     = plaintext
+#  server_set_id              = $auth2
+#  server_prompts             = :
+#  server_condition           = ${if and{{ eq{$auth2}{username} } \
+#                                          eq{$auth3}{password} }} }
+#  server_advertise_condition = ${if def:tls_cipher }
+
+# LOGIN authentication has traditional prompts and responses. There is no
+# authorization ID in this mechanism, so the username and password are
+# $auth1 and $auth2 instead of $auth2 and $auth3. Otherwise it is the same
+# as PLAIN authentication.
+
+#LOGIN:
+#  driver                     = plaintext
+#  server_set_id              = $auth1
+#  server_prompts             = <| Username: | Password:
+#  server_condition           = ${if and{{ eq{$auth1}{username} } \
+#                                          eq{$auth2}{password} }} }
+#  server_advertise_condition = ${if def:tls_cipher }



######################################################################

Tony.
--
<fanf@???> <dot@???> http://dotat.at/ ${sg{\N${sg{\
N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\
\N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}