View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0015264||phpList 3 application||Bounce Management||public||23-04-09 09:14||31-05-12 01:57|
|Product Version||Future developments|
|Target Version||Fixed in Version|
|Summary||0015264: The phplist_bounce address shouldn't accept attachments|
|Description||The phplist_bounce should delete any incoming attachments and accept only text. Many servers also bounce back senders' attachments. It also happens that large attachments cause more bounces (due to over quota).|
So imagine what happens if you send large attachments and gets lots of bounces.
The phplist_bounce address should deal with it somehow.
|Tags||No tags attached.|
||What do you mean be an attachment? A RFC 3464 delivery status notification arguably contains attachments, including crucial information in a message/delivery-status part.|
||Well, in multi-part messages specifically, you could strip every multi-part except the one with Content-Type: text/plain; (and perhaps Content-Type: text/html; but surely there's no need for anything else)|
message/delivery-status is the obvious one - it is designed to be machine parsable and contains important information about the nature of the bounce. What's more, if the original is included as a message/rfc822 part, the headers of that message contain much of information used by phpList to work out who the bounce is from and for what message. Full VERP handling (eg http://forums.phplist.com/viewtopic.php?f=7&t=24796) would get rid of the need to scan the headers of the original, but is only possible with access to a server that will deliver mail to user+extension to the mailbox user.
phpList has no control over how the server delivers mail to its bounce mailbox, only over what it does with it once it has retrieved it from there. Currently I think with most bounces it deletes the whole bounce from the server.
However, it does retain the contents in the database and I would agree that this is not a good strategy. It opens up a potential route for a DDOS attack, filling the drive which the database store is on. What's more, retrieving and slurping into memory the whole of a large message could cause problems. So I would agree that only text/* and message/delivery-status and the headers from message/rfc822 parts need keeping. It would also make sense to set a limit on the size of message to be retrieved. With VERP it is possible to work out who the bounce is for whilst only retrieving the headers, which is a useful fallback position for oversized messages - grab the headers, process and then delete the message from the mailbox.
||Seems related to http://mantis.phplist.com/view.php?id=13391|
||Since, as tipichris pointed out, PHPlist has no control over how your bounce mailbox handles attachments, the only way I can see around this is to parse the mail logs from the server's MTA (postfix, qmail, etc). However, this also has some obvious problems, such as A) Not all MTAs use the same log format, B) The logs from the local MTA may not be accurate. For instance, I work on a PHPlist install on a company network. The MTA on the server where PHPlist is installed merely hands the mail off to the company mail server. I've researched cases where the local MTA reports a success in handing the mail off to the mail server, but the mail server is then unable to deliver the email, so the local MTA reports a false positive.|
in a way, the bouncing MTA shouldn't return attachments, as they are no use to the diagnoses of the bounce. However, I guess that's outside of our control.
I agree that the size of the bounce as stored in the DB should be limited, to prevent (d)DOS or anything like that. Also, it would be good to clean out bounces on a regular basis.