Page MenuHomePhabricator

SparkPost reply-to function support, please
Closed, ResolvedPublic

Description

https://www.mediawiki.org/wiki/Manual:$wgUserEmailUseReplyTo

If $wgUserEmailUseReplyTo is set to true, user-to-user emails will contain the email address of the sending user in a Reply-To: header only, instead of directly in the From: line. Emails will appear to come from $wgPasswordSender, but replies will be sent to the email address of the user sending the user-to-user email.

Document about SparkPost Reply_to api can be found here: https://developers.sparkpost.com/api/transmissions/#transmissions-post-send-inline-content

BTW, their is another setting related to reply-to function too. https://www.mediawiki.org/wiki/Manual:$wgNoReplyAddress

Event Timeline

Zoglun created this task.Feb 5 2019, 10:40 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 5 2019, 10:40 AM

@Zoglun, does that mean when you set $wgUserEmailUserReplyTo = true, it doesn't set the reply_to field in the request header? So this config is not enough?

Zoglun added a comment.EditedFeb 5 2019, 11:37 AM

By far it seems that no reply_to field transferred to SparkPost. Therefore all email sent via user-to-user method does not contain sender's email address in reply-to.

If everything work as expected, $wgUserEmailUserReplyTo = true; should be enough to get sender's email address listed in reply-to field in user-to-user email.

Okay! Let me try to tackle this at the level of this extension then see what is happening deep down within the core then!

Change 488030 had a related patch set uploaded (by D3r1ck01; owner: Derick Alangi):
[mediawiki/extensions/SparkPost@master] Add support for "reply_to" when $wgUserEmailUseReplyTo is set

https://gerrit.wikimedia.org/r/488030

Hmm... so this doesn't relate to core as far as I see, it's just some feature to add to any email extension. I've made a patch which I'll merge soon and you'll test. Thanks :)

D3r1ck01 claimed this task.Feb 5 2019, 12:02 PM
D3r1ck01 triaged this task as Normal priority.

Change 488030 merged by jenkins-bot:
[mediawiki/extensions/SparkPost@master] Add support for "reply_to" when $wgUserEmailUseReplyTo is set

https://gerrit.wikimedia.org/r/488030

@Zoglun, pull and test. Make sure $wgUserEmailUseReplyTo is set to true too. Thanks, looking forward to your feedback.

Is there some bug in the code? No matter who send user-to-user email. The reply field only contain email address password-reset@mail.example.com. It's suppose to be the emaill address of user who initiate the email through page Special:EmailUser. Not the system email address.

Hmmm... not sure but I think that should be normal behavior or expected? Extracted from the $wgUserEmailUseReplyTo page;

MediaWiki installations on a shared server may fail to send user-to-user email due to spam prevention by disabling open mail relaying.
Setting to true may create a privacy issue, as bounces containing the recipient's email address may get returned to the server's sending user email address.
D3r1ck01 added a comment.EditedFeb 5 2019, 12:46 PM

Also, I'm trying to reproduce this using the SendGrid extension to see if it's the same problem! I'll get back to you about this issue. Seems to me as there could be some privacy concerns around this issue as I think "user's" email hides behind that of the config of the wiki for anonymous reasons, not sure if I'm getting this right but I'll get back to you on this!

@Zoglun, I think I know what is happening but like I said, I'll get back to you on this. Thanks :)

@Zoglun, I think I know what is happening but like I said, I'll get back to you on this. Thanks :)

@Zoglun, I've successfully solved this problem in the SendGrid extension and tested locally, it's working fine! Once I confirm that everything is alright, I'll migrate the solution to the SparkPost extension and make a patch. Shortly! :)

Zoglun added a comment.Feb 5 2019, 1:47 PM

Cool!
It's late night in China now. I will test your new code tomorrow (if patch available).

Zoglun added a comment.Feb 9 2019, 5:50 AM

Dear @D3r1ck01 Is there any progress on the patch? Or experiencing any difficulty?

D3r1ck01 moved this task from Backlog to Doing [WIP] on the User-D3r1ck01 board.

Not at all, wanted to clear some privacy concerns! Patch is already ready and coming out soon!

Change 489375 had a related patch set uploaded (by D3r1ck01; owner: Derick Alangi):
[mediawiki/extensions/SparkPost@master] Follow-up on I2dc74829ce9703a7de9421c3

https://gerrit.wikimedia.org/r/489375

Change 489375 merged by jenkins-bot:
[mediawiki/extensions/SparkPost@master] Follow-up on I2dc74829ce9703a7de9421c3

https://gerrit.wikimedia.org/r/489375

@Zoglun, you're up for testing and let me know if it works as expected. Thanks!

Good! Reply-to function seems to work well. I will do more test on it.


We found random content error in user group promote/remove notification email (before & after the reply-to patch, they are irrelevant.). Still trying to figure out the reason.

So what are the random content errors? Any example?

So what are the random content errors? Any example?

Same problem as mentioned in T214664 . Where multiple Content-Transfer-Encoding made contents after the first Content-Transfer-Encoding become random code like =E6 . Might need to reopen T214664 .

Zoglun closed this task as Resolved.Feb 9 2019, 11:08 AM

Reply-to function work in my test. Ула!

Same problem as mentioned in T214664 . Where multiple Content-Transfer-Encoding made contents after the first Content-Transfer-Encoding become random code like =E6 . Might need to reopen T214664 .

I thought this would be solve with the 3 new config variables that were added sometime ago? If all 3 configs are set to false, do we still have gabbled content or random code? If so, I think it could be an issue with SparkPost right? Or if not, we can reopen T214664 and make some investigations.