Add preference to link images

Because these are just picking up the images that are in nodes directly, that content being created by at least a dozen other people. I've also got the same issue with node_announce (which I own) and the print module (which I don't).

In all these cases the mailing modules could be made to preprocess the html before sending it to mimemail. But with 20 lines of code in mimemail it can instead do this at a site level for all the emails sent out, regardless of originator, which is what is desired from a site policy perspective.

That may work fine for a site where the editors are all computer people, but it works very poorly for the non profits I support. They have no idea what kind of link an image has, it's added just via WYSIWYG and the IMCE bridge. They don't have the skills or understanding to go into the html and make those changes. And avoiding training farmers on html is the reason I chose Drupal in the first place. :)

It is exactly the point that for the 3 sites that I support we don't want any embedded images in any email. People complain loudly when their email is getting filled up with the large messages. This is true for all sending of email that we use, coming from multiple modules, as well as mimemail actions.

While this might not be your use case for sending email, I think it's a very common one. Making it site policy just like site policy of whether or not to specify css seems exactly right.

Well, it's unfortunate that you won't fix it, because forcing all the urls to absolute in the code isn't an option. That means we can't have a test server with independent content because the full url is embedded. One of these sites already underwent a name change, and if I'd implemented this the way you said, it would have caused dozens of hours of rework.

Using absolute urls for local content just to work around behavior of mimemail seems really the wrong approach.

Guess I'll just keep maintaining my own patch to mimemail for this.

My interest with mimemail is the fact that it correctly generates multipart/alternative email so there is both an html version and a text version. And I'd been using it for a while, so I was encouraged to add what I considered a useful feature.

I didn't expect this to be so contentious, as it was a relatively small amount of code, that was disabled by default, and just gave mimemail users additional option for usefulness.

I'll look into HTML Mail to see if that would do what I need.

It appears that HTML Mail only provides multipart/alternative if mimemail is installed, which means it would run into the same issue.

hook_mail_alter() approach doesn't seem to work in the test module I just wrote. I don't know if that hook is getting triggered when sending via mimemail. I'll do some more investigation at some point in the future here, because if I can actually made that change without a patch I need to keep rebasing, that would be great.

But the effort in keeping that patch up to date is actually pretty minor compared with completely rearchitecting things to use a different solution here (like correctly integrating and testing one of the approaches that changes the links in the content before they ever get to mimemail).

Sorry we couldn't see eye to eye here, as I really do believe this would be a feature of interest to a number of people.

sgabe thanks for looking into this again.