This topic describes the operation of the Gateway server components. Apart from the TLS setup, both servers share the same code.
Architecture
The SMTP server opens a new thread from a thread pool to handle each attempted connection. There is a thread count limit of 64 which is not expected to be reached. Its failure mode under heavy load is therefore to slow down responses somewhat, which is usual for this type of service. The processing thread is released if the connection can be quickly rejected, so the server is reasonably resilient in the face of attack; but it might require external protection to survive a sustained denial-of-service attempt. Since most messages will arrive from a normal MTA elsewhere on the Internet, they would usually be retried if the server is reduced to a very long response time.
The SMTP server continues to run if a network outage prevents the message-processing component from completing the processing of saved messages. However this requires that the files, and in particular the templates, which are used to validate connections, are held on a local drive.
Start-up
The server configuration details from the registry and the CopiaFacts configuration files are requires at start-up.
The Gateway TLS certificate is loaded and validated if specified. Certificate errors will prevent the service from starting. The certificate expiry date is made available in the registry for the Gateway manager to display.
The Gateway needs to be restarted if the list of recipient domains is changed, or if the certificate is renewed. It does not need to be restarted when sender or recipient templates are changed.
Connection
On every connection attempt a message number is allocated from a batch of numbers managed using the NEXTMSG file in the saved messages folder.
A HELO or EHLO response is always sent.
If 'TLS required' is set and STARTTLS is not sent next by the client, an error 530 will be returned to the sender.
Sender Validation
The first step is to remove any Bounce Address Tag Validation prefix from the sender e-mail address before further processing.
If there is a list valid sender IPs the sender IP is checked against it and rejected if not present.
If there is a list of valid sender domains, the sender address domain name is checked against it and rejected if not present.
There remains the process of Template validation (if not enabled, all senders are valid). The sender template validation depends on the presence of folders and template files; the template files are not opened at this stage.
•If a custom DLL is configured and loaded, the address is accepted: it will be validated later.
•If no sender templates folder has been defined the sender is marked as invalid.
•if there is no folder for the domain (company.com) in the sender templates folder, the sender is marked as invalid unless there is a DEFAULT.FST file in the sender templates folder. A Notification message (GWLOADERROR) is initiated if there is no folder for the sender domain.
•if there is no template for the sender (sendername.FST) in the domain folder the sender is marked as invalid unless there is a DEFAULT.FST file in the domain folder.
•Otherwise, the presence of the template for the sender in the domain folder validates the sender.
Multiple messages for recipients at the domain from this server can be accepted by the SMTP server in one connection. Each one will be allocated a separate message number.
Authentication
Login to the Gateway is not required, but login attempts are recorded in the trace. These are sometimes useful to identify spam attempts, though seeing 'admin;password' will not identify its source.
Recipient Validation
If a custom DLL is configured and loaded, the recipient domain, sender address, and optional sender IP are sent to the DLL for validation. The DLL can return -1 to cause the recipient to be marked as a bad address, 0 to continue with normal template validation, or 1 to use the returned text as if it were the content of a sender template.
At this point the recipient name may be a fax number or a special recipient mailbox name. We first check for a special recipient mailbox name:
•If there is no recipient name the recipient is marked as invalid.
•If the recipient name is 'default' or 'UserTemplate' recipient is marked as invalid. These names are only used for validating senders.
•If the recipient name is not in the recipient domains list it the recipient is marked as invalid.
•If there is no domain folder matching the recipient domain in the recipient domains folder the recipient is marked as invalid.
At this point the recipient may be have a valid special recipient mailbox name, or be a fax number, or be marked as invalid. If it is marked as invalid then an error is returned to the sender: 553 Invalid Address, or 521 Mail not accepted for domain.
We next check for the existence of a recipient template file in the domain folder in the recipient domains folder.
•If there is no recipient template the recipient may be a fax number the recipient is provisionally accepted as valid. The same happens if there is an error loading the recipient template.
•If the recipient template contains an $email_decrypt_keyword command, this is authenticated if it contains a SECRET variable, and the filename and passphrase are extracted and will be saved (and encrypted) in the MIF file.
•If the recipient template does not contain a $worker_box command it is provisionally marked as invalid.
•Otherwise, If the SMTP_OPTIONS variable from the recipient template does not specify that the recipient requires a valid sender, the recipient is provisionally accepted as valid.
No further use is made of the recipient template by the server component.
The final determination of whether to accept the incoming message is then made as follows:
•If the sender has been marked as invalid and the recipient has been marked as provisionally invalid, an error is returned to the sender: 553 Invalid Address.
•If no list of domains acceptable to receive faxes has been configured, the incoming message will be accepted.
•If the recipient domain is in the list of domains acceptable to receive faxes, the incoming message will be accepted.
•If the recipient has already been provisionally accepted (with a recipient template), the incoming message will be accepted.
•Otherwise an error is returned to the sender: 553 Invalid Address.
Saving the Incoming Message
All errors on saving the file are reported in the trace and by initiating a Notification message (GWMSGFAIL).
The raw incoming message is saved to a .TMP file in the Saved Messages folder. If an error occurs which leaves an incomplete file, its extension is changed to .XXX if possible. If the save is successful, the file is renamed to .MSG.
If the save was successful, a .MIF file is also written containing the details of the SMTP transaction. It includes details of the sender, first recipient, and any additional recipients on the TO command; whether HELO or EHLO was used; whether TLS was used; whether a login and password was entered. It also contains (encrypted) the filename and passphrase for the decryption key file (if used), and the text to be used as the sender template contents if the custom DLL provided this.
Closing the Connection
If a command is received following an incoming QUIT command and before the client closes the connection, it initiates a new message from the same sender. If the client fails to close the connection it will time out after 30 seconds.
SMTP Server Errors
If a message error is reported to the sending MTA before a message is completely sent, no error indication is made to the Gateway operator other than messages in the Gateway trace file.
Notification triggers are initiated only on failure to save an incoming message or MIF (GWMSGFAIL) and on failure access the sender templates folder (GWLOADERROR). This avoids notifications occurring when unwanted accesses to the Gateway are attempted.
