I noticed some code in Moodle (I think it's newish) about email bounce handling - what's that all about? I don't remember reading anything
I got to this because Moodle appears to bounce all messages (via the Rteurn-Path header) to the Moodle primary administrator. I was keen to be able to change this - I was going to put in a 'hidden' (ie, config file only) config setting to override this. The motivation is that our Computing people want to be the primary administrator but they don't care about the bounces, they want them to go to the 'real' administrator in the department owning the Moodle site.
Then, of course, I saw this bounce stuff.......
Guilty over here.
We put it in to 1.5, we've been running it on our cluster for a few months now. It's quite tricky to set up, but once you get it running, it allows you to track the bounce ratio for any given student and force them to change their email address if it reaches a magic number.
Here's the original thread, complete with setup instructions
http://moodle.org/mod/forum/discuss.php?d=18374
We put it in to 1.5, we've been running it on our cluster for a few months now. It's quite tricky to set up, but once you get it running, it allows you to track the bounce ratio for any given student and force them to change their email address if it reaches a magic number.
Here's the original thread, complete with setup instructions
http://moodle.org/mod/forum/discuss.php?d=18374
As things are going, it'll be labelled experimental for 1.5, and we'll work on refining it and documenting it better. I wrote a wiki page documenting the setup on Exim/Postfix/qmail. It is at http://moodle.org/mod/wiki/view.php?id=2935&page=Email+Processing+setup
One point is that, at this stage, it depends on your email server not lowercasing the "local-part" of the address (the bit to the left of the @ sign). To cope with modern email servers, which tend to lowercase the local-part, we are moving the code to use base32 instead of base64. This pretty much halves the amount of data we can encode in the local-part.
To cope with this impoverished interface, we'll be using an "email session cookie" table.
As you can see, some of these things are in the air a bit. It does work at the moment, but it hasn't stabilized yet.
Of course, you are welcome to play with it ;)
One point is that, at this stage, it depends on your email server not lowercasing the "local-part" of the address (the bit to the left of the @ sign). To cope with modern email servers, which tend to lowercase the local-part, we are moving the code to use base32 instead of base64. This pretty much halves the amount of data we can encode in the local-part.
To cope with this impoverished interface, we'll be using an "email session cookie" table.
As you can see, some of these things are in the air a bit. It does work at the moment, but it hasn't stabilized yet.
Of course, you are welcome to play with it ;)