Feature Wiki

Information about planned and released features

Tabs

SMTP-Settings-Page

Page Overview

[Hide]

1 Initial Problem

The current status is that ILIAS uses the existing mailsystem that is provided by the server, like postfix etc.

This is a significant limitation when multiple ILIAS clients or web applications run on the same webserver and need different mail configuration, especially different mail relay servers.

Related forum discussion (society-members only): http://www.ilias.de/docu/goto_docu_frm_1844_2264.html

2 Conceptual Summary

  • the mail settings are split into two new sub-tabs
    • general 
    • external
  • new option to connect to stmp server instead of using the built-in PHPMailer, when activated the following smtp-specific settings can be set
    • host (string)
    • port (integer)
    • encryption (SSL or STARTTLS)
    • user (string)
    • password (string) -- if this is set, the username becomes a conditionally required field
  • the above smtp settings are only used to connect to the smtp-server
  • we also suggest some minor name changes and re-ordering of options to streamline the mail settings as a whole
see mockups and explanations in chapter "User Interface Modifications" for more details

2.1 Update-Steps

  • DB-Update-step will migrate all current settings and map them to the new settings for system-mails (user-mail settings will start with the new defaults / empty)

2.2 Not-Included

  • Signatures
    • Translation of signatures for system mails would require significant refactoring of the mail-system. Therefore it is not part of this feature request. It will only be possible to set the currently hard-coded signature independently of any language system-wide
    • There will be no global signature for user emails, since users can choose their own signature. A future extension could be a global default signature
  • This feature does not address the way emails are processed. ILIAS does not have a queue for sending mails. This may be another future improvement (cf. asynchronous background tasks).
  • No user-specific SMTP-Settings. SMTP-Settings will be system-wide.
  • Reply-to is not respected by all email clients (some webmail clients). ILIAS cannot guarantee that this is repected by the email client.

3 User Interface Modifications

3.1 List of Affected Views

  • Administration > Mail (modified)
    • new sub-tab: General
    • new sub-tab: External

3.2 User Interface Details

explanation below the picture

  • replace "Globally Prevent External Mails" (default: No) with "External Mails" (default: Yes). Add a short by-line "Allow ILIAS to sent mails to external email adresses"
  • rename "Send Mail Notifications" with "New-Mail Notifications". The old name could be confused to enable sending notifications via mail in general. The new name stresses that this enables notifications about new mails.
  • the following settings are moved into the next sub-tab
    • Sender Fullname (from)
    • Return Path / Envelope-From
    • No-Reply Adress
    • Mail Subject
    • HTML Frame

explanation below the picture

This sub-tab is completely new and contains some existing, but also brand-new settings

  • sender fullname + email and return path can now be set independently for user mails and system mails
  • the sender fullname for user emails supports the following placeholders
    • [FIRSTNAME]
    • [LASTNAME]
  • the signature of system mails can now be edited (previously hardcoded) and has the following placeholders
    • [CLIENT_NAME]
    • [CLIENT_DESC]
    • [CLIENT_URL]
  • we suggest minor renaming of some of the existing settings as shown in the mockup
    • HTML Frame for External Emails -> HTML Frame
    • Reply-To Address -> Reply-To
    • Return-Path -> Return-Path (Envelope-From)
    • Sender Name -> Sender Fullname (From)

Behaviour and defaults:

System-Mails

  • Return Path / Envelope-From (default = EMPTY)
    • ILIAS will then not set this mail-header, when left empty. Setting this header is then left to the mail-server (it is the task of the system administrator to find meaning full configurations).
    • existing and new installations will default to the following signature:
* * * * *
[CLIENT_NAME]
[CLIENT_DESC]
[CLIENT_URL]

User-Mails
  • Sender Fullname, default:
    • [FIRSTNAME] [LASTNAME]
  • Return Path / Envelope-From (default = EMPTY)
    • ILIAS will then not set this mail-header, when left empty. Setting this header is then left to the mail-server.
  • The following header are automatically set by ILIAS and cannot be edited
    • Reply-To: ILIAS will use the Sender Email here.
    • From: ILIAS will use the user fullname plus Sender Email here. The fullname can not be overwritten.

3.3 New User Interface Concepts

No new interface elements.

4 Technical Information

There are not dependencies to other components. The should't be any performance impacts, the mail queue is handled by the respective mail server at not part of this implementation.

5 Contact

  • Author of the Request: Kiegel, Colin [kiegel] (2016), Wolfgang Hübsch, admin@bbs-ilias.de (2013)
  • Maintainer: Jansen, Michael [mjansen]
  • Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

6 Funding

If you are interest in funding this feature, please add your name and institution to this list.

7 Discussion

Ralf Schenk, Databay AG: For me as a system-integrator such a feature is long expected since its abscence leads to constant additional effort in configuring an supporting ILIAS systems of any kind. It's especially annoying since valid return-path/envelope header information has to be implemented by postfix masquerading like genrics-table mapping. Also required authentication to send mail for relaying to external recieipients is always a pain in the ass to configure or let the customer implement workarounds.

JF 17 Feb 2014: We appreciate the feature and schedule it for 4.5.

JF 13 Oct 2014: We still appreciate the feature and schedule it for 5.1.

Hesse, Joel [Joel_Hesse] The majority of the members of the SIG Corporate which voted at the 7th of September 2016 appreciate this feature request, too.

Kiegel, Colin [kiegel] 2016-09-22: I fleshed out the details of this request after a discussion with Michael Jansen, Ralf Schenk and Joel Hesse. This feature will greatly improve administrators lives when dealing with more complex mail scenarios.

IMO one question remains:

  • Should it be possible to customize the "Sender Fullname (From)" for user mails? This is currently not possible and also with this request in its current form. The problem is, that there is no one-fits-all solution. One installation may prefer the account name, another one firstname + lastname, another one might want to use the (matriculation) id - or a combination like "[firstname] [lastname] ([login])" <[email]>. The best approach would be to make this customizable with a small set of placeholders, namely: firstname, lastname, login and possibly (matriculation) id.

JourFixe, ILIAS [jourfixe], Oct 10, 2016: Due to open discussions, request needs to be discussed in a follow-up workshop.

Kiegel, Colin [kiegel] 2016-10-11: The following points have been clarified according to the discussion

  • for user generated emails, the setting sender email is now specified as a required field.
  • for user generated emails, the sender fullname is now specified as an editable field with placeholders.
  • for system emails, the signature setting is now specified to have placeholders and default to the currently hardcoded text.
  • the setting mail subject (prefix) is moved to the top section of external mail to reflect the ILIAS behaviour that it is prepended to both system and user mails.
I have also hidden the initial draft, which caused some confusion.

JourFixe, ILIAS [jourfixe]: Oct 24, 2016: We highly appreciate the revised feature request and schedule this feature for 5.3.

Hesse, Joel [Joel_Hesse] 19.06.2017 - Bug left: Even if the system was not able to send the mail, a success message appears. I would expect a detailed error message or a link / path to a useful error log.

Jansen, Michael [mjansen] 22 Sept, 2017: @Joel: This is not a  real bug. If SOAP is enabled in the ILIAS administration, the external SMTP emails are sent via a seperate and asynchronous HTTP (SOAP) request (fire and forget). The initiating process (triggered by your actions in the ILIAS user interface) does not receive any response/status. So currently you have to check the ILIAS log file.

Maybe the delivery process for emails (initiated by a real user, not by the system itself) should be migrated to a background task ('Background Tasks' are available since ILIAS 5.3.x) as a new (not so big) feature. Then this task appears in the ILIAS header and we can display the status of the email transport.

8 Implementation

Implemented as described above, except:

  • Return-Path (Envelope-From):
    • Desired Behaviour: Empty ILIAS will then not set this mail-header, when left empty. Setting this header is then left to the mail-server (it is the task of the system administrator to find meaning full configurations).
    • Implemented Behaviour:
      • SMTP: Because of the underlying library the 'MAIL FROM' header will not be left empty in any case. If nothing is defined in ILIAS, the 'FROM' header is used as 'MAIL FROM'.
      • Native PHP/sendmail: If left empty, it is the server administrator's responsibility to configure this value.
    • The label was renamed from 'Return-Path (Envelope-From)' to 'Technischer Absender [de]/Technical Sender[en]) and affects the 'Sender' mail header. Email senders should never set a return-path header; it's the receiver's job (RFC5321 section 4.4).

Test Cases

Test cases completed at 04.05.2017 by Jansen, Michael [mjansen]

Modified test case:

Approval

Approved at 22.06.2017 by Hesse, Joel [Joel_Hesse].

Last edited: 22. Sep 2017, 12:34, Jansen, Michael [mjansen]