[RLUG] MTA Attachment Idea

[Rick Shepherd]

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 david at fluffybunny.com

 

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 carl at happysquirrel.com.  

Bill receives email as billy at happysquirrel.com. 

Larry receives email as larry at happysquirrel.com.

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.

1.	The email is delivered to each of the three recipients generating
45MB of outbound email at one moment.
2.	The email is bounced to David indicating the attachment is too large
and David is now confused and there is a potential that it generated an even
larger load if the attachment remains on the inbound message.

 

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: 918dfkfJ4 at ftp.fluffybunny.com/ 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.  

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rlug.org/pipermail/rlug/attachments/20060726/bc0160d1/attachment.html