(no commit message)
[ikiwiki.git] / docs / developer / EnhanceDmaGSoC.mdwn
index 5a60b25..c9e901b 100644 (file)
-# enhance dma(8) during the SoC 2008 \r
-A [Google Summer of Code 2008](http://code.google.com/soc/2008) project.<<BR>> Student: Max Lindner<<BR>> Mentor: Matthias Schmidt<<BR>>\r
-\r
-## Project Proposal Abstract \r
-dma - a minimalistic non-listening mta for dragonflybsd shall gain some more functionality regarding processing and delivering mail.\r
-\r
-The project adresses two main subjects:\r
-\r
--smart delivery to smarthosts\r
-\r
--support for .forward local delivery\r
-\r
-## Status \r
-\r
-finished\r
-\r
-## Timeline \r
-Until May 25th - reading dma source, creating build environment, get to know the development cycle in dragonflybsd, refine timeline, more detail on this page ;-)\r
-\r
-May 26th until Jul 06th - creating .forward handling and test it\r
-\r
-Jul 07th until Jul 14th - Midterm Evaluation\r
-\r
-Jul 15th until Aug 10th - improve smarthost handling\r
-\r
- **Add .forward support** \r
-\r
-Any combination of the following entries should be valid in a .forward file:\r
-\r
-    \r
-    |/pipe/to/executable\r
-    mailbox@remote.host\r
-    !deliverdirekttomailbox\r
-\r
-dma runs as root and splits itself up into 3 branches now:\r
-\r
- 1. the old codebase, which drops privileges to user nobody / group mail\r
- 1. a process for reading an users .forward (the function dotforwardhandler), which forks for every file to read and drops privileges to that user before reading.\r
- 1. a process for writing an users mailbox/executing the pipe for delivering the mail (the function write_to_local_user), which forks for every mail to deliver and drops privileges to that user before open the file/pipe\r
-\r
-The communication between the 3 branches is done via two socketpairs, one socketpair for each new branch. In order to prevent concurring communication, it is synchronised with one semaphore each.\r
-\r
-The new processes terminate themselves as soon as every mail which was enqeued was sent out or bounced. This is signaled by another semaphore which is incremented before delivery starts and decremented after the mail was successfully sent or written or the bounce was generated and delivered.\r
-\r
- **Smarter smarthost-delivery** \r
-\r
-for implementing the new smarthost delivery, I use the new function deliver_smarthost. While the function deliver takes one qitem a time, the deliver_smarthost function takes a queue. This queue is generated during go_background and is the main queue with having removed the local receipients. This queue is given to the deliver_remote function, which sends one "RCPT TO: xy@foo.bar " for each qitem.\r
-\r
-Depending on the returning status code (accept, temporary error, permanent error) the qitem is copied to one of 3 other queues. These 3 queues are processed again in deliver_smarthost after completing the deliver_remote function. Sent qitems are deleted, temporary failed items are tried again and permanent failed items are bounced.\r
-\r
-For the cram-md5 authetification, I changed the read_remote() function to the possibility to give back the received buffer. Inside of this buffer, there is a challenge which must be used together with the username and password to create a appropriate response.\r
+# enhance dma(8) during the SoC 2008 
+
+A [Google Summer of Code 2008](http://code.google.com/soc/2008) project. <br>
+Student: Max Lindner<br>
+Mentor: Matthias Schmidt
+
+
+
+## Project Proposal Abstract 
+
+dma - a minimalistic non-listening mta for dragonflybsd shall gain some more functionality regarding processing and delivering mail.
+
+
+
+The project adresses two main subjects:
+
+
+
+-smart delivery to smarthosts
+
+
+
+-support for .forward local delivery
+
+
+
+## Status 
+
+
+
+finished
+
+
+
+## Timeline 
+
+Until May 25th - reading dma source, creating build environment, get to know the development cycle in dragonflybsd, refine timeline, more detail on this page ;-)
+
+
+
+May 26th until Jul 06th - creating .forward handling and test it
+
+
+
+Jul 07th until Jul 14th - Midterm Evaluation
+
+
+
+Jul 15th until Aug 10th - improve smarthost handling
+
+
+
+ **Add .forward support** 
+
+
+
+Any combination of the following entries should be valid in a .forward file:
+
+
+
+    
+
+    |/pipe/to/executable
+
+    mailbox@remote.host
+
+    !deliverdirekttomailbox
+
+
+
+dma runs as root and splits itself up into 3 branches now:
+
+
+
+ 1. the old codebase, which drops privileges to user nobody / group mail
+
+ 1. a process for reading an users .forward (the function dotforwardhandler), which forks for every file to read and drops privileges to that user before reading.
+
+ 1. a process for writing an users mailbox/executing the pipe for delivering the mail (the function write_to_local_user), which forks for every mail to deliver and drops privileges to that user before open the file/pipe
+
+
+
+The communication between the 3 branches is done via two socketpairs, one socketpair for each new branch. In order to prevent concurring communication, it is synchronised with one semaphore each.
+
+
+
+The new processes terminate themselves as soon as every mail which was enqeued was sent out or bounced. This is signaled by another semaphore which is incremented before delivery starts and decremented after the mail was successfully sent or written or the bounce was generated and delivered.
+
+
+
+ **Smarter smarthost-delivery** 
+
+
+
+for implementing the new smarthost delivery, I use the new function deliver_smarthost. While the function deliver takes one qitem a time, the deliver_smarthost function takes a queue. This queue is generated during go_background and is the main queue with having removed the local receipients. This queue is given to the deliver_remote function, which sends one "RCPT TO: xy@foo.bar " for each qitem.
+
+
+
+Depending on the returning status code (accept, temporary error, permanent error) the qitem is copied to one of 3 other queues. These 3 queues are processed again in deliver_smarthost after completing the deliver_remote function. Sent qitems are deleted, temporary failed items are tried again and permanent failed items are bounced.
+
+
+
+For the cram-md5 authetification, I changed the read_remote() function to the possibility to give back the received buffer. Inside of this buffer, there is a challenge which must be used together with the username and password to create a appropriate response.
+