Public Member Functions | |
| processMail ($msg) | |
Protected Member Functions | |
| validateHeaders ($headers) | |
| parseEmail ($content) | |
| rfcCompliant ($str) | |
Detailed Description
This is a PHP script designed to receive emails. Postfix (and perhaps other MTAs) can deliver a message to a program rathan than a mailbox. This script is meant to receive those kind of piped messages.
The main idea is to provide a pathway for a host on the general internet to send a message to Fannie without allowing access to HTTP/HTTPS/MySQL. There are validation/authentication concerns no matter what the mechanism, but I think this approach has some advantages in terms of keeping responses to external inputs tailored really, really narrowly. It does add "mail server admin" to the list of hats the IT staff has to wear though.
The initial usage I have in mind is signing up members via the co-op's website. When someone signs up on the site, the website would send an email to the store with their information encoded somehow (JSON, probably) and then this script could use that information to update the database. Using a mysql driver that supports prepared statements properly would be highly recommended since this increases the danger of malicious input a fair amount.
For validation, I think I'll prepopuldate a set of member accounts on the POS side with some kind of random hexadecimal key on each account (likely via custdata.blueLine) and push them out to the website. The incoming member signup messages could then be required to provide the correct hex key for the account they are creating. Headers could be validated, too (From, originating server, etc) but since it's all spoofable I don't know if it's even worth bothering.
Prepopulating accounts on the website does open the possibility that new memberships could become "out of stock" which is rather silly, but that should be fairly simple to avoid with a generous initial allocation and then fine-tuning based on results. It would eliminate most of the risk of accidentally giving out the same number twice if one customer is signing up in the store while another is signing up online.
Member Function Documentation
|
protected |
Parse email message
- Parameters
-
$content [string] raw email
- Returns
- keyed array
- header => key:value [array] of headers
- body => [string] raw body
- invalid => [array] of malformed lines
I highly doubt this is 100% RFC2822 compliant. Shouldn't matter for use cases I'm considering, but take "invalid" with a grain of salt. It just means my validation says it isn't a correctly formatted header line.
|
protected |
Check if string is an RFC2822 field name Field names should contain characters between ASCII 33 and 126 except for ":" (ASCII 58)
- Parameters
-
$str [string] to check
- Returns
- [boolean]
The documentation for this class was generated from the following file:
- fannie/classlib2.0/data/pipes/NewMemberEmailPipe.php
