dirname() is a slow function compared with __DIR__ and using
'/../'. Moodle has a large number of legacy files that are included
each time a page loads and is not able to use an autoloader as it is
functional code. This allows those required includes to perform as
best as possible in this situation.
This patch contains:
* email_to_user will set the envelope sender to a special bounce processing address (based on $CFG settings)
* email_to_user will accept (and set) a reply-to header, to be generated by the module calling the function.
* new functions:
* generate_email_processing_address - ALWAYS use this to generate the reply-to header. reply-to header will look like this:
(LIMIT: 64 chars total)
prefix - EXACTLY four chars
encodeded, packed, moduleid (0 for core) (2 chars)
up to 42 chars for the modules to put anything they want it (can contain userid (or, eg for forum, postids to reply to), or anything really. 42 chars is ABSOLUTE LIMIT)
16 char hash (half an md5) of the first part of the address, together with a site "secret"
* moodle_process_email - any non-module email processing goes here (currently used for processing bounces)
* bounce handling:
* config settings for bounce threshold and ratio (and whether to handle bounces at all)
* if too many bounces occur against any given user, user_not_fully_set_up will force an email address change
* associated functions (over_bounce_threshold, set_send_count, set_bounce_count)
* handling emails to noreply address (see below)
* new script - admin/process_email.php
This script needs to be called from your mail program for anything starting with the 4 char prefix described above (and optionally, the noreply address)
It will bounce emails to the noreplyaddress, with a friendly "this is not a real email address" message
It will break down and unencode the email address into moduleid and validate the half md5 hash, and call $modname_process_email (if it exists). Arguments to these functions are: $modargs (any part of the email address that isn't the prefix, modid or the hash) and the contents of the email (read from STDIN).
* associated string changes/additions
* changes in config-dist.php to give clues as to how to set this up.
MODULE WRITERS!
take a look at new functions moodle_process_email and generate_email_processing_address in moodlelib.php for ideas about how to
* encode and unencode the arguments your module needs to do the processing
* how to deal with multiple "actions" for any given module.
Martin Langhoff <martin@catalyst.net.nz> will be writing up some PROPER documentation, containing amongst other things config settings for different mail servers (this was developed against Postfix). Feel free to email me with any feedback on the code or design, penny@catalyst.net.nz. Or post on the developer fourm.
