Qremote(8)

NAME
Qremote - send mail via (E)SMTP

SYNOPSIS
Qemote host sender recip [ recip ... ]

DESCRIPTION
Qemote reads a mail message from its standard input and sends the message to one or more recipients at a remote host. The standard input must be a descriptor of a file opened for reading, Qremote will fstat(2) and mmap(2) it. The remote host is Qremote's first argument, host. Qremote sends the message to host, using the routing algorihm described below. or to a mail exchanger for host listed in the Domain Name System, via the Simple Mail Transfer Protocol (SMTP). host can be either a fully-qualified domain name:
         mail.example.com
or an IP address enclosed in brackets:
         [192.0.2.19]
or an IPv6 address enclosed in brackets:
         [::ffff:192.0.2.19]
The envelope recipient addresses are listed as recip arguments to Qremote. The envelope sender address is listed as sender.

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. Qremote converts single CR or LF into the SMTP newline convention by converting them to CRLF. If the message contains non-ascii characters the message is encoded as quoted-printable if the remote server does not support the 8BITMIME extension defined in RfC 1652. If a message contains lines with more than 1000 characters it is always recoded to quoted-printable, sending such a long line would be a SMTP protocol violation. Qremote supports the CHUNKING extension defined in RfC 3030. If the remote server supports CHUNKING no message recoding is done at all.

RESULTS
Qremote 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: temporary failure.

D   Message report: permanent failure.

After this letter comes a human-readable description of what happened. No human readable description is printed after 'r' status report ( qmail-rspawn would get confused otherwise). The recipient reports will always be printed in the same order as Qremote's recip arguments. Note that in failure cases there may be fewer recipient reports than recip arguments. Qremote always exits zero.

CONTROL FILES
The files listed in this section are looked up in the subdirectory control/ of the qmail directory. All files are optional.

clientcert.pem
    SSL certificate that is used to authenticate with the remote server during a TLS session.

helohost
    Current host name, for use solely in saying hello to the remote SMTP server. Default: me, if that is supplied; otherwise Qremote refuses to run.

outgoingip
    The local IPv4 address used when sending out mails. Use this if your machine has multiple addresses and you want your mail coming from a specific one.

outgoingip6
    Works the same as outgoingip, but for IPv6 addresses.

smtproutes
    Artificial SMTP routes. See below for a detailed description of mail routing. The format of this file is the same as used by qmail-remote . Each route has the form hostpattern:relay[:port], without any extra spaces. The port specification is optional. The following 2 lines have the same effect:
           foo.example.com:mx2.example.com
           foo.example.com:mx2.example.com:25
    The first matching entry will be used. hostpattern may start with a dot, matching all subdomains of the given domain, but not domain itself. relay may be empty, causing the default routing mechanisms to be applied, this can be used to either only specify a different destination port or to route one domain using the default mechanism that would otherwise be matched by a later rule. The following example will route foo.example.com using the default mechanism, but any other subdomain of example.com to mail.example.net. example.com is also routed using the default mechanism as it is not matched by any rule:
           foo.example.com:
           .example.com:mail.example.net

smtproutes.d
    Artificial SMTP routes. This is a more extensible format than the plain smtproutes file, allowing easier addition of other properties for the target host while keeping the files readable. See below for a detailed description of mail routing. A file can be created for each domain to specify a specific routing. Wildcard routings may be created using a file beginning with a single * as subdomain, e. g.
          *.example.net
    Make sure to escape the * character when accessing these files from a shell as the shell will use this character as glob extension. Each file contains key=value pairs defining the mapping. Currently the following keys are supported:

        relay
            The hostname of the target machine.

        port
            The port on the remote machine to connect to.

        clientcert
            The TLS certificate to use when connecting.

        clientkey
            The TLS key to use when connecting. If not given clientcert is used.

        outgoingip
            The IPv4 address used when connecting to the remote server.

        outgoingip6
            The IPv6 address used when connecting to the remote server.
    Duplicate keys are forbidden. Lines beginning with a hash sign '#' and empty lines are ignored. Given the domain foo.example.net the following lookups will be performed:
         smtproutes.d/foo.example.net
         smtproutes.d/*.example.net
         smtproutes.d/*.net
         smtproutes.d/default
    The search is terminated on the first match. Please note that a wildcards subdomain does not match mails with the absolute destination of the remainder, e. g. *.example.net does not match for a mail sent to foo@example.net Only values from one file are considered, if a value is not set in the first matching file no further files will be scanned for that value. Every value that is not explicitely given will be taken from the default control files as specified above. The following example would route mails to port 24 on baz.example.org :
           host=baz.example.org
           port=24

timeoutconnect
    Number of seconds Qremote 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 Qremote will wait for each response from the remote SMTP server. Default: 1200.

tlsclientciphers
    A set of OpenSSL client cipher strings. Multiple ciphers contained in a string should be separated by a colon.

tlshosts/<FQDN>.pem
    Qremote requires authentication from servers for which this certificate exists (<FQDN> is the fully-qualified domain name of the server). One of the DNSname or the CommonName attributes have to match. WARNING: this option may cause mail to be delayed, bounced, doublebounced, or lost.

MAIL ROUTING
    By default Qremote will look up the host given as it's first argument in the DNS system, looking for MX entries. If none such entry is found it will look for AAAA or A records for this hostname and use them. If neither is found, a temporary error will be announced, causing the mail to remain in the queue or eventually being bounced if it has stayed there for too long. The routing may be influenced using the smtproutes control file or the files in the smtproutes.d directory. See above for a description of the syntax rules that apply to these files.
        The routing algorihm is as follows:

            search for a matching entry in smtproutes.d

            search for a matching entry in smtproutes

            search for MX entries for the target host

            search for AAAA and A entries for the target host
    If a match in the first 2 steps is found the relay specified Qremote will connect to relay, as if host had relay as its only MX. (It will also avoid doing any CNAME lookups on recip.) If relay is empty this tells Qremote to look up DNS records as usual, but apply any other properties specified in the control files (e.g. different target port). 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.

DEBUGGING
If Qremote has been with the DEBUG_IO flag the contents of the SMTP transmissions can be recorded. They will be sent to the syslog daemon with facility mail and log level debug. The contents of the SMTP DATA phase will never be logged for privacy reasons. Logging is not enabled by default. If the file control/Qremote_debug is readable on startup logging will be enabled. Therefore it will usually not harm to compile that facility into the program.

SEE ALSO
fstat(2), mmap(2), addresses(5), envelopes(5), qmail-control(5), qmail-send(8), Qsmtpd(8), qmail-tcpok(8), qmail-tcpto(8)

AUTHOR
Rolf Eike Beer

WEBSITE
https://opensource.sf-tec.de/Qsmtp/