GSP
Quick Navigator

Search Site

Unix VPS
A - Starter
B - Basic
C - Preferred
D - Commercial
MPS - Dedicated
Previous VPSs
* Sign Up! *

Support
Contact Us
Online Help
Handbooks
Domain Status
Man Pages

FAQ
Virtual Servers
Pricing
Billing
Technical

Network
Facilities
Connectivity
Topology Map

Miscellaneous
Server Agreement
Year 2038
Credits
 

USA Flag

 

 

Man Pages


Manual Reference Pages  -  QMAIL-REMOTE (8)

NAME

qmail-remote - send mail via SMTP or QMTP

CONTENTS

Synopsis
Description
Transparency

SYNOPSIS

qmail-remote host sender recip [ recip ... ]

DESCRIPTION

qmail-remote reads a mail message from its input and sends the message to one or more recipients at a remote host.

The remote host is qmail-remote’s first argument, host. qmail-remote sends the message to host, or to a mail exchanger for host listed in the Domain Name System, via the Simple Mail Transfer Protocol (SMTP/ESMTP) perhaps encrypted via STARTTLS/TLS or the Quick Mail Transfer Protocol (QMTP). host can be either a fully-qualified domain name:

silverton.berkeley.edu

or an IP address enclosed in brackets:

[128.32.183.163]

In case the primary mail exchanger for that Domain will issue a 5xy reply message during the connection, qmail-remote will contact all responsible mail exchangers in turn in order to deliver the message anyway.

The envelope recipient addresses are listed as recip arguments to qmail-remote. The envelope sender address is listed as sender.

Note that qmail-remote does not take options and does not follow the getopt standard.

TRANSPARENCY

End-of-file in SMTP is encoded as dot CR LF. A dot at the beginning of a line is encoded as dot dot. It is impossible in SMTP to send a message that does not end with a newline. qmail-remote converts the UNIX newline convention into the SMTP newline convention by inserting CR before each LF.

It is a violation of the SMTP protocol to send a message that contains long lines or non-ASCII characters. However, qmail-remote will happily send such messages. It is the user’s responsibility to avoid generating illegal messages.

RESULTS

qmail-remote prints some number of recipient reports, followed by a message report. Each report is terminated by a 0 byte. Each report begins with a single letter:
r Recipient report: acceptance.
h Recipient report: permanent rejection.
s Recipient report: temporary rejection.
K Message report: success. host has taken responsibility for delivering the message to each acceptable recipient.
Z Message report: greylisted or temporary failure.
D Message report: permanent failure.
After this letter comes a human-readable description of what happened.

qmail-remote may use SMTP Authenticaton to connect to remote hosts. The following reports are provided:

K no supported AUTH method found, continuing without authentication.
Z Connected to host but authentication was rejected (AUTH PLAIN).
Z Connected to host but unable to base64encode (plain).
Z Connected to host but authentication was rejected (plain).
Z Connected to host but authentication was rejected (AUTH LOGIN).
Z Connected to host but unable to base64encode user.
Z Connected to host but authentication was rejected (username).
Z Connected to host but unable to base64encode pass.
Z Connected to host but authentication was rejected (AUTH CRAM-MD5).
Z Connected to host but unable to base64decode challenge.
Z Connected to host but unable to base64encode username+digest.
Z Connected to host but authentication was rejected (username+digest).
The recipient reports will always be printed in the same order as qmail-remote’s recip arguments. Note that in failure cases there may be fewer recipient reports than recip arguments.
In case a CNAME can not be resovled qmail-remote issues the following message:
Z CNAME lookup failed temporarily for: host.
If a SMTP connection is bound to a none-existing IP address qmail-remote will complain with the message:
Z System resources temporarily unavailable.
In case a QMTP connection can not be established qmail-remote will issue the error message:
Z recipient host did not talk proper QMTP.
On demand qmail-remote supports TLS/STARTTLS and will use the following messages:
K TLS transmitted message accepted.
Z Can’t load X.509 certificate.
Z I wasn’t able to create TLS context.
Z I wasn’t able to process the TLS ciphers.
Z I wasn’t able to setup CAFILE or CADIR for TLS.
Z I wasn’t able to establish a TLS connection with: host.
Z I wasn’t able to gracefully close the TLS connection with: host.
Z Unknown TLS error for host: host.

qmail-remote always exits zero.

CONTROL FILES

authsenders
  Authenticated sender. For each sender included in authsenders: sender:relay:port|user|password qmail-remote will try SMTP Authentication of type CRAM-MD5, LOGIN, or PLAIN with the provided user name user and password password (the authentication information) and eventually relay the mail through relay on port port. The use of relay and port follows the same rules as for smtproutes Note: In case sender is empty, qmail-remote will try to deliver each outgoing mail SMTP authenticated. If the authentication information is missing, the mail is delivered none-authenticated. authsenders can be constructed as follows:

@example.com:relay.example.com|user|passwd
info@example.com:relay.example.com:26|infouser|infopasswd
:mailrelay.example.com|e=mc2|testpass

domaincerts
  In case qmail-remote needs to present a client certificate to the server (for authentication purposes) the PEM encoded X.509 certificate can be provided per sending domain: domain:certificate|keyfile|password. If domain equals ’*’ this certificate is used as default. The file certificate may include the private key, thus keyfile can be ommitted. Additionally, the private key can be protected with a password.

domainips
  IP addresses to be used on outgoing connections. Each line has the form domain:localip|helohost, without any extra spaces. If domain matches the domain part in sender, qmail-remote will bind to localip when connecting to host. If it matches, it will set the provided HELO string as greeting; otherwise, it will use the default.
helohost
  Current host name, for use solely in saying ehlo/hello to the remote SMTP server. Default: me, if that is supplied; otherwise qmail-remote refuses to run.
qmtproutes
  Additional QMTP routes which have precedence over smtproutes. QMTP routes should obey the form domain:relay:port, without any extra spaces. qmtproutes follows the same syntax as smtproutes. By default, qmail-remote connects to QMTP service port 209. However you can chose a dedicated high-port for QMTP communication as defined in qmtproutes.
smtproutes
  Artificial SMTP routes. Each route has the form domain:relay or domain:relay|user|password without any extra spaces. If domain matches host, qmail-remote will connect to relay, as if host had relay as its only MX. (It will also avoid doing any CNAME lookups on recip.) host may include a colon and a port number to use instead of the normal SMTP port, 25. In case, a userid and password is present, qmail-remote will try a SMTP authenticated session:

inside.af.mil:firewall.af.mil:26
:submission.myrelay.com:587|myuserid|mypasswd

relay may be empty; this tells qmail-remote to look up MX records as usual. smtproutes may include wildcards:

.af.mil:
:heaven.af.mil

Here any address ending with .af.mil (but not af.mil itself) is routed by its MX records; any other address is artificially routed to heaven.af.mil.

Additionally, smtproutes allows to forward bounces (with a ’Nullsender’ MAIL FROM: <>) literally expressed as ’!@’ to a particular bounce host:

!@:bouncehost.af.mil:27

The qmail system does not protect you if you create an artificial mail loop between machines. However, you are always safe using smtproutes if you do not accept mail from the network.

timeoutconnect
  Number of seconds qmail-remote will wait for the remote SMTP server to accept a connection. Default: 60. The kernel normally imposes a 75-second upper limit.
timeoutremote
  Number of seconds qmail-remote will wait for each response from the remote SMTP server. Default: 1200.
tlsdestinations
  If present, this file advices qmail-remote to use TLS encryption for specific destination domains as provided by the forward-path and perhaps to validate/verify the domain’s server certificate: destination:cafile|verifydepth:port|ciphers|domain. Unless explicitely configured, qmail-remote accepts any or no certificate provided by the server, thus uses TLS for encryption only. Example:

*:
.example.com:
securityfirst.com:/etc/ssl/cafile||!SSLv2:HIGH
.remote.com:/etc/ssl/certdir/|3:465
mx.partner.com:/etc/ssl/partnerca||:26|mydomain.net
=mx.myfriend.com:/etc/ssl/cacert|4
-.adhonlydomain.com:|aNULL:!kRSA
=*:
hiddenpartner.org:||:35
!nosslhost.example.com:

This first line tells qmail-remote to use STARTTLS to any TLS capable ESMTP server. The second line requires from qmail-remote to demand a STARTTLS connection for any destination address targeting domain .example.com.

The third line accepts STARTTLS connections for securityfirst.com only, if the X.509 certificate can be verified against the CA cert as provided via /etc/ssl/cafile and with the acceptable ciphers SSLv2:HIGH.

Line number four tells qmail-remote to use a SMTPS connection on port 465 to any host at .remote.com and accept this host only, if the peer’s cert can be verified against a (hashed) CA cert available in /etc/ssl/certdir/ and does not exceed a verification depth of 3.

Line five shows an example, how tlsdestinations can be bound exclusively to a sender domain. In this case, only if mx.mydomain.net is used as sender domain, a connection for the destination address mx.partner.com is mandatory secured by TLS with a CA cert available as /etc/ssl/partnerca with a verification depth of 2.

Furthermore, if qmail-remote sees a destination address concatinated with a = it will only accept the certificate, if the X.509’s DN can be validated against the FQDN of the server (by means of a DNS lookup) and it verifies against the cacert CA certificate and does not exeed a verification depth of 1.

In case, no perticular ciphers or CA certs are required, a double-colon ’::’ can be used as shortcut followed by the port.

In the same sense, qmail-remote may accept TLS connections based on Anonymous DH (ADH) - where the server does not provide a cert for authentication - once the domain name is prepended with a -. Here, a wildcard ’*’ for the domain name is allowed. qmail-remote will announce ADH aNULL as key encryption cipher and discards !RSA for authentication if told so.

Finally, the last line instructs qmail-remote to ommit the STARTTLS command for the recipient address nosslhost.example.com as indicated with a leading !.

If port equals 465, SMTPS will be used instead of STARTTLS.

Note that ’destination’ is subject of the forwarding rules as provided by authsenders, qmtproutes, and smtproutes.

SEE ALSO

addresses(5), envelopes(5), qmail-control(5), qmail-send(8), qmail-smtpd(8), qmail-tcpok(8), qmail-tcpto(8)
Search for    or go to Top of page |  Section 8 |  Main Index


QMAL-REMOTE (8) -->

Powered by GSP Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.