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 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.



