179 lines
8.6 KiB
Plaintext
179 lines
8.6 KiB
Plaintext
News
|
|
====
|
|
|
|
Overview
|
|
--------
|
|
The E-MailRelay 2.5 release is no longer just a store-and-forward SMTP relay or
|
|
proxy; it can do routing (improved from 2.4), client account selection and
|
|
message delivery, making it more useful as a general-purpose MTA. Routing and
|
|
client account selection are activated by having an external filter script to
|
|
edit e-mail message envelope files.
|
|
|
|
Multiple configurations
|
|
-----------------------
|
|
In previous releases E-MailRelay runs with one spool directory and typically
|
|
one SMTP server and one SMTP client doing store-and-forward. In this release
|
|
one E-MailRelay process can have multiple configurations, each with their own
|
|
independent spool directory, SMTP server and SMTP client. Everything still
|
|
runs single-threaded (except as documented in "developer.txt").
|
|
|
|
Refer to the reference document for more details.
|
|
|
|
More built-in filters and address verifiers
|
|
-------------------------------------------
|
|
E-MailRelay allows filters that are not simple scripts by using command-line
|
|
options like "--filter=exit:99" and "--filter=spam:localhost:783", with a
|
|
small number of special prefixes like "exit:", "net:", "file:" and "spam:".
|
|
|
|
In this release there are more built-in filters and address verifiers, including
|
|
"deliver:", "split:", "mx:", "copy:" and "msgid:" filters and the "account:"
|
|
address verifier.
|
|
|
|
Refer to the reference document for more details.
|
|
|
|
Delivery
|
|
--------
|
|
E-MailRelay can now act as a Message Delivery Agent (MDA) so it can deliver
|
|
e-mail messages to local mailboxes according to the e-mail addressees.
|
|
|
|
A mailbox is a simple sub-directory of some delivery base directory, defaulting
|
|
to the spool directory. So Alice's mailbox might be the "alice" sub-directory
|
|
"/var/spool/emailrelay/alice", containing envelope and content files. Or it
|
|
can have its own "maildir" structure, "/var/spool/emailrelay/alice/new,cur,tmp",
|
|
in which case the content file will be delivered to the "cur" directory and
|
|
there will be no envelope file.
|
|
|
|
Refer to the reference document for more details.
|
|
|
|
Client account selection
|
|
------------------------
|
|
This release allows for multiple client accounts to be used for SMTP
|
|
authentication when forwarding. A new "ClientAccountSelector" field in the
|
|
envelope file must match against the fifth field of a "client" line in the
|
|
secrets file. A filter should be used to fill in the selector field in the
|
|
envelope, typically based on the message addressing.
|
|
|
|
When the account changes from one message to the next the SMTP connection is
|
|
dropped and re-connected. It is necessary to drop the connection because some
|
|
common SMTP servers do not allow re-authentication within an existing SMTP
|
|
connection.
|
|
|
|
Client rows in the client secrets file can now have a fifth field for the
|
|
selector, but this raises a backwards compatibility issue because in previous
|
|
releases the fifth column (and beyond) in a client secrets file is ignored and
|
|
might be a comment without a leading '#' character. In upgrading, the first word
|
|
of the comment would be treated as a selector and the "client" row would be
|
|
effectively disabled resulting in a failure of message forwarding. Therefore,
|
|
fifth fields in the secrets file that start with '#' are treated as comments
|
|
(extending to the end of the line) and lines in the secrets file with six or
|
|
more fields result in a warning. It follows that filters should not generate
|
|
selectors starting with a '#' character.
|
|
|
|
Local files
|
|
-----------
|
|
In previous releases ".local" message files were created for messages with local
|
|
recipients (as determined by an address verifier) in order to create a separate
|
|
path for messages sent to the local postmaster. These files are no longer
|
|
created because E-MailRelay can now run multiple filters in a chain and it is
|
|
easy enough to write a filter to separate out these messages.
|
|
|
|
7BIT/8BITMIME
|
|
-------------
|
|
Previous versions of E-MailRelay test message content when a message is received
|
|
and populate the "Content" field of the envelope file as either "7bit" or
|
|
"8bit". However, the SMTP client code has always largely ignored this field and
|
|
it would attempt to forward 8-bit messages to a remote server that did not
|
|
advertise 8BITMIME, albeit with a warning in the log.
|
|
|
|
In this release E-MailRelay no longer tests messages for eight-bit content,
|
|
so the envelope "Content" field will always be "8bit". If this is not the
|
|
desired behaviour then a filter script should be used to test for seven-bit or
|
|
eight-bit content and edit the "Content" value in the envelope file accordingly.
|
|
|
|
If necessary the SMTP client can now be made to behave more strictly so that it
|
|
does not try to forward eight-bit messages to seven-bit servers (see
|
|
"--client-smtp-config").
|
|
|
|
PIPELINING
|
|
----------
|
|
This release adds support for the PIPELINING SMTP extension.
|
|
|
|
Previous releases allow pipelining of the SMTP QUIT command but otherwise
|
|
require SMTP requests and responses in turn (as per RFC-5321 2.1). In this
|
|
release the SMTP server code allows all SMTP commands to be pipelined, whether
|
|
or not the PIPELINING extension is advertised. The PIPELINING advertisement can
|
|
be disabled with the new "--server-smtp-config" command-line option.
|
|
|
|
The response batching behaviour described by RFC-2920 is not implemented.
|
|
|
|
The SMTP client code uses pipelining only for MAIL-FROM and RCPT-TO SMTP
|
|
commands when talking to a remote server that supports the PIPELINING extension.
|
|
This can be disabled using the "--client-smtp-config" command-line option so
|
|
then each MAIL-FROM or RCPT-TO request waits for a response before continuing.
|
|
|
|
CHUNKING/BINARYMIME and SMTPUTF8
|
|
--------------------------------
|
|
This release adds support for the CHUNKING+BINARYMIME and SMTPUTF8 extensions
|
|
to SMTP, although they are disabled by default.
|
|
|
|
It is important to note that if CHUNKING+BINARYMIME or SMTPUTF8 support is
|
|
enabled in the E-MailRelay server then the destination next-hop server must
|
|
also support these extensions. If the remote server does not support these
|
|
extensions then messages may fail immediately when they are forwarded.
|
|
|
|
In principle filter scripts can be used to convert BINARYMIME and SMTPUTF8
|
|
messages to non-BINARYMIME and non-SMTPUTF8 forms (RFC-3030 calls these
|
|
"gateway transformations"), but it might be easier to leave these extensions
|
|
disabled in the E-MailRelay server if there is any doubt about the capabilities
|
|
of the next-hop server.
|
|
|
|
In previous releases address verifiers only need to deal with printable ASCII
|
|
addresses because of the character-set retrictions imposed by the SMTP protocol.
|
|
But if the the SMTPUTF8 extension is enabled in the E-MailRelay server then the
|
|
addresses passed to any address verifier script might contain UTF-8 characters
|
|
and this might require changes to the script.
|
|
|
|
In passing, note that recipient addresses given to address verifier scripts are
|
|
as they appear on the wire, so a badly-behaved SMTP client might send addresses
|
|
containing double-quotes and backslash escapes that are semantically redundant.
|
|
For example, a message submitted to "\A\l\i\c\e"@example.com will have that
|
|
address passed to the verifier with all the redundant double quotes and
|
|
backslashes present. Normalising an address by removing quotes and backslashes
|
|
is reasonably easy in ASCII but might be more tricky with UTF-8.
|
|
|
|
Another corner case with SMTPUTF8 is that the remote client might use the VRFY
|
|
SMTP command without the optional SMTPUTF8 parameter. In principle a UTF-8
|
|
address verifier script should not then return UTF-8 results, but in practice
|
|
the script has no way of knowning whether the SMTPUTF8 parameter was used. If
|
|
necessary the VRFY command can be disabled by using "--anonymous".
|
|
|
|
Hashed passwords
|
|
----------------
|
|
Hashed passwords created by "emailrelay-passwd" that use the SHA-1 or SHA-256
|
|
hashing algorithm will no longer work when E-MailRelay is built using the latest
|
|
versions of the OpenSSL and MbedTLS libraries. Both libraries have stopped
|
|
exposing the relevant state variables used within their hashing functions. MD5
|
|
hashed passwords will still work.
|
|
|
|
Code size
|
|
---------
|
|
The source code now contains a lot of conditional compilation directives like
|
|
"#ifndef G_LIB_SMALL" that reduce the size of the built binaries.
|
|
|
|
The Windows build and the build of the GUI on Linux are not affected because
|
|
they are built without the "G_LIB_SMALL" switch.
|
|
|
|
These extra directives make the code rather ugly so they can be removed if
|
|
necessary by running:
|
|
|
|
libexec/reduce.sh --undo
|
|
|
|
Filter-copy utility
|
|
-------------------
|
|
The emailrelay-filter-copy utility was included in previous releases as a
|
|
set-user-id file program to copy e-mail message files into sub-directories for
|
|
"--pop-by-name" access. This can now be done by the built-in "copy:pop" filter,
|
|
albeit with minor differences in behaviour, so emailrelay-filter-copy has been
|
|
removed.
|
|
|