« CSS inheritance issue
Mail entities and stuff.
Sources/notifiers »

Nao

  • Dadman with a boy
  • Posts: 16,082
Mail entities and stuff.
« on April 10th, 2013, 11:17 AM »
I'm stupid.
I have stupid ideas.

But sometimes, even though they're stupid simple, they're just like, "uh? why didn't I think of that before..?!"

In this case, I just received a notification e-mail (after subscribing to the stuff), and noticed that it had <URL> in it. Woops... Okay, I should be careful about sending notification data by e-mail, replacing <URL> manually instead of through the output buffer handler, because it's never called on these...

And then it struck me.
What prevents us from adding this at the beginning of the sendmail() function..? Uh?

Code: [Select]
$message = ob_sessrewrite($message);

Duh.
Then it just... gets converted like a normal web page would. We could even automatically convert things to entities on the fly, too. Every time a mail is sent, it's passed through sendmail(). Then why bother doing 'special e-mail handling' inside $txt in this situation...?

There's probably a reason... But I can't find any. I told you -- I'm stupid.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Mail entities and stuff.
« Reply #1, on April 10th, 2013, 01:15 PM »
Problem: stuff can be passed through sendmail TWICE. You'd have to ensure it's only passed to the rewrite function the first time. (Look in the source for mentions of the 'hotmail_fix', since that's the trigger to send it through again)

As far as special handling goes, you're right. You're absolutely right. Consider: if a post contains these things, it's still going to get sent so why should it matter if $txt contains them too?
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Mail entities and stuff.
« Reply #2, on April 10th, 2013, 03:08 PM »
Quote from Arantor on April 10th, 2013, 01:15 PM
Problem: stuff can be passed through sendmail TWICE. You'd have to ensure it's only passed to the rewrite function the first time. (Look in the source for mentions of the 'hotmail_fix', since that's the trigger to send it through again)
Good to know. And good to know that you agree with me... :)
Quote
As far as special handling goes, you're right. You're absolutely right. Consider: if a post contains these things, it's still going to get sent so why should it matter if $txt contains them too?
Don't get what you mean here...?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Mail entities and stuff.
« Reply #3, on April 10th, 2013, 10:54 PM »
Quote
Don't get what you mean here...?
We don't have any controls over what's in a post, save for ensuring that quotes are saved as entities (which we do, for both kinds of quote) And we don't entitify everything as it currently stands. Since emails go out with post contents with no apparent problems (though we should retest this with accented UTF-8 characters to be absolutely sure), I don't see why there is a problem with the in-between bits doing exactly the same thing.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Mail entities and stuff.
« Reply #4, on April 12th, 2013, 12:24 AM »
I applied the ob_ change to Subs-Post here, and tested sending a mail to myself... It works, but there are issues -- for instance, we should add an option to disable shortening of URLs because it ends up stripping the domain name out of the links, oops... I added a temp $context variable, I guess I just need to set it at sendmail time.

There's also another problem with HTML... It shows up as plain code. I'm thinking that there isn't much of a reason NOT to send HTML emails by default... If anything, it kinda defeats the purpose of ob_ to send as plain text, because tags are shown in all their glory... :-/

Or, maybe we should simply fix that and turn anchor tags into text.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Mail entities and stuff.
« Reply #5, on April 12th, 2013, 12:29 AM »
Just be *extremely* careful doing that. The rewriter is not a cheap process if you have to factor in things like looking up pretty URLs - and if you're doing the DB lookup every call, that's potentially DB queries every time you send an email. For some cases, that's not horrible - one off emails are fine. But newsletters... not so much.
Quote
I'm thinking that there isn't much of a reason NOT to send HTML emails by default...
There are some email services that treat such things as more likely to be spam.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Mail entities and stuff.
« Reply #6, on April 12th, 2013, 07:35 PM »
- $message is parsed only once, AFAIK, and then sent to multiple recipients (i.e. sendmail() supports multiple recipients). So I don't think there's any problem with the number of calls to PURL code...

- Then what should we do? Convert anchors to text..?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Mail entities and stuff.
« Reply #7, on April 12th, 2013, 08:23 PM »
Quote
- $message is parsed only once, AFAIK, and then sent to multiple recipients (i.e. sendmail() supports multiple recipients). So I don't think there's any problem with the number of calls to PURL code...
That wasn't what I meant. There are plenty of times the content will be different each message. The sort of scenario I'm thinking of is the notifications for outstanding topics for moderation - it will be different for every language, but the links still have to be parsed multiple times as a result (once per language)

Not to mention that sendmail can still pass its own content BACK to itself. But that's less of an issue.
Quote
- Then what should we do? Convert anchors to text..?
I don't know. I really don't know, and truth be told I'm having a real hard time keeping everything else straight in my head.
« CSS inheritance issue
Sources/notifiers »