Popfetcher Plugin: Wishes for enhancement

[blog.brockha.us]

Now that Posterous is closing the popfetcher plugin is becoming more and more important I think. I tested it on my testblog and found some problems and feature wishes I had. Is anyone still maintaining this plugin? If not I would perhaps take some time to work on it..

Sender email

In the configuration the option is described as "put your sender email here if you want to allow only posts from this email". If I do so my mails are declined because my mail client is sending as

<"Grischa Brockhaus" name@domain.tld> (not name@domain.tld only)

If I put the complete string into this option it works but won't if I send from another client sending with email only. So there should be some parsing making the plugin detect the email (no matter in what form it comes).

And I would like to define more than one email address. A csv list would be okay.

Image attachments

When I sent emails with attachments from my Android phone (using K9) the post is published and the attachment is put into my mediadatabase, but the image is not part of the post. Only when I do add [attach:1] explicitly to my email text the image is added at this position.

On twitter I learned that this should (and does) work w/o the [attach:n], too, but it doesn't in my case. Perhaps this is a problem with form of email my client is sending? I would see this as bug.

Thumbs vs big images

This is setup globally. I would like to change this from post to post, so perhaps we could use something like [thumb:n] vs [image:n] ([attach:n] would be "like configured" to be backward compatible).

Other attachments types?

I tried an email with video attached. This is not supported, so it seems. Would be cool, to support video and audio, too. We would need some players / html5 code to make this work, though.

More?

Well, there could be more, Posterous could be an example, what the popfetcher could do (resizing images to max sizes, galleries, ...)

Anybody interested?

[garvinhicking]

Hi!

If I put the complete string into this option it works but won't if I send from another client sending with email only. So there should be some parsing making the plugin detect the email (no matter in what form it comes).

The problem is that the parsing would need to make sure that mail adresses can't easily be faked like:

"<grischa@brockha.us>" <mail@garv.in>

That's the reason why currently it is a full string check, and not a substring. Multiple mail addresses shouldn't be too hard...

When I sent emails with attachments from my Android phone (using K9) the post is published and the attachment is put into my mediadatabase, but the image is not part of the post. Only when I do add [attach:1] explicitly to my email text the image is added at this position.

On twitter I learned that this should (and does) work w/o the [attach:n], too, but it doesn't in my case. Perhaps this is a problem with form of email my client is sending? I would see this as bug.

In the past it has been a major pain on how different mail clients upload different attachments differently in a differing differ. You might want to check the debugging option of the popfetcher plugin to analyze your incoming email and see where and how the specific parts are parsed/ignored.

Thumbs vs big images

This is setup globally. I would like to change this from post to post, so perhaps we could use something like [thumb:n] vs [image:n] ([attach:n] would be "like configured" to be backward compatible).

Good idea!

Other attachments types?

I tried an email with video attached. This is not supported, so it seems. Would be cool, to support video and audio, too. We would need some players / html5 code to make this work, though.

I think uploading videos via email could be a bit problematic also due to size, and since parsing of the email takes up lot of RAM and so PHP could easily choke on processing the email.

Best regards,
Garvin

[blog.brockha.us]

Thanks for answering, Garvin!

The problem is that the parsing would need to make sure that mail adresses can't easily be faked like:
"<grischa@brockha.us>" <mail@garv.in>

Ah.. Uh.. Hmm.. This indeed is a problem to think about. But it could be handled, too, I think, not? Of course it has to be some sort of "smart parsing" detecting what really was "name faked as email" and what was the email..

In the past it has been a major pain on how different mail clients upload different attachments differently in a differing differ. You might want to check the debugging option of the popfetcher plugin to analyze your incoming email and see where and how the specific parts are parsed/ignored.

Okay, I understand this. But.. The attachment was found and added to the gallery.. If this is the case, than the plugin should add it to the post no matter if there is an [att.n] text or not, right? I think there is some situation in the plugin code, that "forgets" to add the found and saved attachment..

I think uploading videos via email could be a bit problematic also due to size, and since parsing of the email takes up lot of RAM and so PHP could easily choke on processing the email.

Of course. This is optional.. If the user is sending video to the popfetcher he/she should know if the server is able to handle this. Perhaps we should add a warning to the configuration, but having this feature would be very cool. I tested it already with the popfetcher: It finds the video, puts it into the gallery but does not know how to handle it yet. So it is working in principle, only the adding to the post is missing. My testvideo was not that small but the processor was able to handle it.

[garvinhicking]

Hi!

Ah.. Uh.. Hmm.. This indeed is a problem to think about. But it could be handled, too, I think, not? Of course it has to be some sort of "smart parsing" detecting what really was "name faked as email" and what was the email..

Yeah sure, this is definitely handlebar.

However one would need to simply cross mordor, I mean, check the correspondig RFCs to make sure that possible valid mail address syntaxes are all handled without being exploitable.

[quoteOkay, I understand this. But.. The attachment was found and added to the gallery.. If this is the case, than the plugin should add it to the post no matter if there is an [att.n] text or not, right? I think there is some situation in the plugin code, that "forgets" to add the found and saved attachment..
[/quote]

there are specific routines that handle the attachments itself, and a routine that puts attachments that were placed INLINE at the proper part of the code. If that inline matching algorithm doesn't work, you'll have a situation like yours; file was saved, but the plugin couldn't see where inside the email you wanted it.

Of course. This is optional.. If the user is sending video to the popfetcher he/she should know if the server is able to handle this. Perhaps we should add a warning to the configuration, but having this feature would be very cool. I tested it already with the popfetcher: It finds the video, puts it into the gallery but does not know how to handle it yet. So it is working in principle, only the adding to the post is missing. My testvideo was not that small but the processor was able to handle it.

Well I think the parsing mechanism should have central places on where file extensions are handled...so this should be workable!

Regards,
Garvin