Want to automatically process email attachments based on username and subject

I'm seeking advice about setting up an email gateway so students can email me homework and the email will be processed automatically.

For example, if a studenta@univ.edu emails me with a subject of "CS208 hw1", I would cross check studenta in a list of students taking CS208, then take all the attached files, dump them in that student's hw1 folder and respond with an email stating what files were received and when. If the student's email was malformed in some way such as bad subject, or missing files, the service would send an appropriate email.

I have administrative access to an on-campus Linux machine that could be configured as an email server.

Offhand I was thinking of using fetchmail and a cron job to consistently read a designated user's email and perform the appropriate responses with some sort of script. Does this sound like a good way to go? I would welcome better ideas?

I expect that in practice there will be far, far more exceptions to whatever rules you prescribe than there will be conforming mail which is properly handled. You'll be buying yourself a headache of manual fixups and "the computer ate my homework" claims.

Since this is a CS 200 level class, require them to use some version control system and save yourself the hassles of parsing free-format e-mail with the rigid structure that a VCS imposes. Your students will benefit too from the requirement. If my 10-year-old could appreciate the merit of automatic revision control within Google Docs, I'm guessing your students can handle Mercurial or git or even (gasp!) Subversion.

added in response to comment

Yes, but with Mercurial (and presumably git) "repository" is a fancy word for "directory" and is not the heavyweight DBMSy thingy that older VCS models may have led you to expect.

Here is how as a student I would expect to work on a hypothetical assignment:

studenta@dorm$ hg clone https://Rich.univ.edu/studenta/cs208
$ cd cs208 ; broswer ./hw1.html
$ mkdir hw1 ; cd hw1 ; make my work files 
$ hg add * ; hg commit -m "perfect the first time!" # updates locally only
$ make lots of bug fixes
$ hg commit -m "okay really done now"
$ hg push 
# sleep, party, go to class with hangover
$ hg pull
$ browse hw2.html ; mkdir hw2 
...

The assignments in the student's repository placed there by you was just for the sake of demonstration. Since you "own" the Rich.unix.edu machine, their pushes become authoritative. You'd

1. Write a (tiny) script to hg init $student/cs208 on Rich.univ.edu for each student in the roster.
2. Figure whether HTTPS or SSH works best in your environment
3. Add commentary - if desired - to the student's files that they'd pick up on their next pull
4. Have a managed, convenient, logged record of all the interactions.
5. The students get affirmative feedback at the moment of push that it was accepted

Finally, should the repository server be down they could

$ hg export tip | mail -s "server down; assignment done" Rich@univ.edu

And you'd still have a timestamped, digested version of their submission which has a rigid format which you could commit for them, or better still:

"Dr. Rich, the server was down!!!"
"But you sent me an export via e-mail, yes?"
"Of course, sir."
"Well, just push when the machine is back up, I already have proof that you completed it on time."
"Oh gee, Dr. Rich, you're swell!"