|
Hello All, I have been to the Postfix site, checked through some forums and asked Google but I can’t find a ready-built postfix answer to an idea I have. If someone knows of a solution of course I am interested in hearing about it. If not, I would like to know if there is a person/group that can take on this project. If it does not exist I would like to create this as an RPM (if possible) and offer it freely to the community. I am willing to pay to have it developed but I think it is a good enough idea that everyone could benefit from it. Additionally, if someone could incorporate the controls into a Webmin module, or as an add-on the current Postfix Webmin module, that would be great. MTA Attachment Project Observation: Users have no concept of email file attachment size limits or bandwidth usage. Observation: Users are unwilling to learn to do something new unless it is faster or easier than their current methods. Proposal: Strip email attachments at the SMTP server and insert an FTP/HTTP link. Setting: Mail server on site. User David Company Fluffy Bunny Amalgamated Domain fluffybunny.com User email [EMAIL PROTECTED] Scene: David creates an email to his good friends Carl, Billy and Larry. David’s three friends work at Happy Squirrel Enterprises Carl receives email as [EMAIL PROTECTED] Bill receives email as [EMAIL PROTECTED] Larry receives email as [EMAIL PROTECTED] David attaches a 15MB file to his very work-related email. The name of the attachment is naughty.wmv. David sends the email. In a traditional SMTP environment there are two things that would possibly occur.
Programming to the rescue: When the outgoing mail hits David’s SMTP server it is checked for file attachments. If there is an attachment and it is greater than some threshold the attachment is removed. The server creates a directory with a randomly generated name and places that folder in a publicly accessible location (FTP/HTTP). It puts the attachment in that read-only folder. It password protects the folder. After a period of time (hours, days, weeks, etc) it expunges the folder and its contents. The outgoing email would continue to its destination but without the attachment. Instead, the email would contain a link, username and password such as: ftp://ftp.fluffybunny.com/ldic$4239/naughty.wmv Username: david (derived from sender email or generated if desired) Password: 918dfkfJ4 (generated) Include a second link with the path embedded such as: ftp://david: [EMAIL PROTECTED]/ ldic$4239/naughty.wmv Include a text string in the email body telling the recipient how to get his file. Result: Users don’t have to learn to do anything. Immediate reduction in SMTP traffic by 45MB in this example. Future FTP/HTTP traffic for each user likely to occur non-concurrently smoothing out demand cycles. Possibility to incorporate Bittorrent technology for file distribution. Recipient email filters are less likely to reject the mail based on size limits. Failed/rejected email will not generate inbound and outbound load. Mobile users will not be delayed with large attachments over unreliable connections. Perform the same procedure as above for an on-site POP3 server so that all inbound mail is processed before delivery. |
_______________________________________________ RLUG mailing list [email protected] http://lists.rlug.org/mailman/listinfo/rlug
