Support Forum
Support Forum
Offline
We are running into an issue with the post by e-mail addon for the Simple:Press plugin. Currently when we receive large images ( in our case, we were recieving 3.3 MB sized images ), the message is not deleted from the mailbox but is marked as 'read'. The message does in fact post to the forums, but since it isn't removed, the message ends up being posted multiple times.
We were thinking that adding a check to make sure that the message was not read before posting it to the forums would be a good addition to get rid of this particular issue. Would it be possible to get a fix for this in the near future
In the meantime, could this issue be caused by the frequency that the mailbox is checked? Currently, it is set to check every 60 seconds.
Offline
I am actually amazed that your email inbox and the download of the email is happy to even consider 3.3MB downloads although limits are not as tight a they used to be. Obviously I would advise against it simply because of the bandwidth and drain on performance of loading those images over and over for users to view. It is a huge cost. But... leaving that aside...
I would suggest that 60 seconds is really outrageously short, especially if you have a thread already downloading a 3.3 MB image file. There is no doubt a second thread 60 seconds later is likely to start to open and download the same email. And I also doubt it would even be marked as read in that time either.
Sadly there are known problems with the php IMAP routines as far as deleting an email when processed. It is notoriously iffy. On the whole we don't see that many problems and, until proven otherwise, I would still attribute your issue to the 60 seconds. But we can not discount other factors.
I will have to go back to the short and very patchy documentation to see if we are able to check if an email had been 'read' but that might come with it's own problems if we were able to.
 |
YELLOW
SWORDFISH
|
Offline
I had a 62kb image attached to a reply by email post. The post made it but the image didn't. The image was on the server though, as I could access it via webmail. And unfortunately until I actually went in and put it in the trash bin, it kept reposting. Over and over and over. More than 100 times before I caught it and put it in the trash bin. And after all that the attachment never made it to the forum.
So just wondering if I should make it clear to everyone that they cannot send an attachment via email or if this is a bug or something that could be fixed.
edited to add:
The time between posts is set as whatever was default, I think 1800
All email posts go just fine, just anything with an attachment gets reposted over and over.
Offline
This is the first report of a problem with an image attachment not arriving. That part of the code is actually pretty rugged and tried and tested unlike the built in php routines which are, as I said to the user above, quite flaky but all we really have to work with.
The only thing that comes to mind on this is that t could be down to the email client being used to send the email to the forum. For example I know a few people have had problems using gMail for this - although none have reported image issues but that just might be because they did not try that. What was the email client in question please? And what type of attachment exactly?
What I would be interested to know is (a) if there are any errors reported in the post by email log and (b) any related errors (actual errors - not notices/warnings) in the forum error log. Can you let me know?
|
YELLOW
SWORDFISH
|
Offline
Yellow Swordfish said
This is the first report of a problem with an image attachment not arriving. That part of the code is actually pretty rugged and tried and tested unlike the built in php routines which are, as I said to the user above, quite flaky but all we really have to work with.The only thing that comes to mind on this is that t could be down to the email client being used to send the email to the forum. For example I know a few people have had problems using gMail for this - although none have reported image issues but that just might be because they did not try that. What was the email client in question please? And what type of attachment exactly?
What I would be interested to know is (a) if there are any errors reported in the post by email log and (b) any related errors (actual errors - not notices/warnings) in the forum error log. Can you let me know?
a) All the entries (and there were almost the whole fifty for this one post) showed posted successfully.
b) No errors in the forum error log.
Re Gmail... the account sent from was a gmail account. Meaning I was sending TO the forum email account FROM my personal gmail account. The server associated with the forums (the email address I was sending to) is on the hostgator servers.
The image was a .png file
Offline
How about the Email Post Log? - Also found in the toolbox.
Has this happened before or has this been successful in the past?
Offline
And I would ask if there is any chance of trying the same post and image from a different client. GMail has caused a few other issues in the past - all unsolvable so far I am afraid. The technology for this is not as rugged as one would think it is sadly and when it comes to email lots of clients do so much differently.
|
YELLOW
SWORDFISH
|
Offline
Hey Yellow Swordfish et. all,
Thank you for staying on top of this issue - I'd like to turn the attention back to the original post topic.
Our initial investigation led us to believe there was an issue with the image file size and the interval; however, this is not the case.
This is going to be a lengthy reply and will address a lot of our concerns. I appreciate you taking the time to support this plugin. I hope we can get it straightened out once and for all. 🙂
This is from one of our developers that has been spending a lot of time looking into why this is occurring.
Line ~724 on sp-plupload-components.php was using the function move_uploaded_file() (http://php.net/manual/en/funct.....d-file.php) to try and move the email attachments from the /tmp/ directory to the forum users upload directory in sp-resources.
The problem with that move_uploaded_file() is that it will run a check to make sure the file it's trying to move is a legitamately uploaded file, which means the file exists in the $_FILES array of the current page laod and was uploaded via POST method. The post by email plugin doesn't do that. It uses fwrite() to take the image from the email, and write it to the /tmp/ directory... and then tries to move it with move_uploaded_file()... but that function basically responds with false, or "Nope, nope moving that file because it wasn't uploaded the way I need it to be uploaded)".The solution was to use rename() instead of move_uploaded_file()... which is actually used somewhere else in the same file. Using rename(), or copy()... or aynthing that doesn't use security checks isn't incredibly secure. But, you guys have plenty of checks in place to make sure only users with valid emails can post... so you're fine. There's also MIME check's as well to make sure only valid files can be uploaded. Lots of other checks, too.
As shown in this screenshot ()
.. the pluploader addon is deliberately designed to DIE anytime it runs across a situation where that attachment isn't good. All of those die's in that screenshot (and many more) sit between the forum thread creation and the imap delete function. So, you're still vulnerable to something happening to an attachment, the script dying, not deleting the email on hover, then the plugin will poll again later (whatever you have the cron set to) and try to repost that email again. There's WAY too much going on for us to just remove or replace those die's and be fully confident that it doesn't produce any other symptoms. Also notice the line after the dies aren't being run because the die is stopping the script.
The core problem was that the mailbox was being opened in POP3 mode and not IMAP, despite the configuration being set to IMAP. This was why the Unseen and Recent header fields were never correct and so attempts to ignore messages that have already been read weren't working.
Offline
It's getting quite late here in he UK and I am going to need some time to absorb and study this as well as talk to colleagues here - but I wanted to let you know I am not ignoring you...
|
YELLOW
SWORDFISH
|
Offline
Sorry,. It has been an unexpectedly hectic day and I have a hectic weekend and first half of next week coming up.
The first point to make is that I can now replicate your issue with attached images. What interests me most, first up that is and what I want to investigate first, is what has changed in the image uploader code since I last performed a test as I do feel that this should be my first port of call to get a better understanding of what is going on.
Using move_uploaded_file() is just fine as long as the uploader has processed things as expected and clearly this is what has gone awry somewhere. Having said that I would like to thank you guys for the code examples and fixes you have put in place.
As this is not going to be a quick turnaround on my part I would like to get confirmation form you that this is currently working as you want it to. I will feel more comfortable giving it the time it needs knowing that you have it working OK...
|
YELLOW
SWORDFISH
|
All RSS1 Guest(s)