Quick ideas about MidCOM mail importing interface

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

MidCOM General email importer
=============================

- - MDA "sitefinder"
   - called either via "bouncefinder" or via fetchmail
   - CLI PHP
   - takes in mail body and possible bounce status
   - parses the to address
     - if contains reserved strings like "topic-<GUID>" parses the guid
   - based on possible guid and to address determines correct SG and  
possibly
     component
   - POSTs to sites midcom-exec email importer script
     - returns 0 if all ok
     - returns 1 all not ok
       - suggest similar heuristics as in supportmda.pl from OpenPSA1
- - alternate MDA "bouncefinder"
   - called by local SMTP server
     - requires special MX configuration etc.
   - based on SMTP envelope (in environment) detects if the message  
is a bounce
   - calls "sitefinder" with bounce status passing on mail body
- - alternate MDA "urlposter"
   - practically a cleaned up supportmda.pl from OpenPSA1
   - for very simple installations, avoids the complexity of  
"sitefinder"
- - email importer script in midcom-exec(-org.openpsa.mail)
   - takes in POST with
     - mail body
     - mail to address
     - guid - optional
     - isbounce - optional
     - component - optional
     - some data for sanity checking, like mail body size
       - do mind possible automatic charset conversions thus byte size
         may differ by some amount, checksum will certainly not match
   - based on available information determines component then calls
     the components interface class method (either import or bounce)
     passing on mail body and given GUID or if not given the topics  
GUID.
     - the component is responsible from here on
       - we should probably librarize some common "authentication"  
methods
         - from check
         - secret string in headers check
         - combinations of above
         - PGP signature
           - idea: allow signing/encryption of mails to be sent as  
well ?
   - the script in exec will just call relevant methods in the library
     not do any of this (except maybe sanity checking) itself
- - component / topic guid determination
   - applies to email importer and sitefinder
   - searches for parameters with 'org.openpsa.mail-importer' as domain,
     names are wathed email addresses and values are arbitary, to be  
evaluated
     by the handling component
     - this used to determine topic GUID of no other GUID is available
   - PONDER: how to prevent malicious user registering already used  
email
     address watcher
     - for example support emails can be quite confidential
     - OTOH allowing multiple components/instances all watch for  
particular
       address could be beneficial
     - if we decide not to allow duplicate watchers then we must not use
       parameters for storage
       - how to make easily configurable in component configuration ??


## Related: bouncefinder-MUA (jlz)

- - used to send emails where bounces should be cathed
- - called with arguments
   - to (rcpt to)
   - token (usually guid)
   - optionally evenlope from (mail from) skeleton
     - MUA constructs real envelope address from this and the token
     - if not given MUA will use default value
- - actual mail source passed to stdin as usual
- - org.openpsa.mail (rambo) needs some methods/properties to define which
   backend to use and with what parameters
   - this is true for the default SMTP backend as well

Henri Bergius
Consultant Partner, Nemein
henri.bergius-ZpG/[email protected]

Midgard CMS
www.midgard-project.org



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFDvSC7NkT8k497k9IRApkuAJ9fBoqQO7miZeVWswmHSMFCphMXnwCdEenI
j/cNjN3o2GXBxHDDpNZQ19s=
=muqv
-----END PGP SIGNATURE-----