2.0 - wrong return path email on user validation

[makitso]

Not sure on this one.

User registered and then acknowledged the email sent. However, it looks like the the Return Path used the wrong email address.

This is an automated message from Tiger Technologies, the company that provides service for skatekey.net.

The attached message was undeliverable because it was sent with a "Return-Path" sender address of "makitso@gmail.com", instead of a valid address ending with "@skatekey.net".

[fisharebest]

There is a tree configuration option: "webtrees reply address".

What value do you have it?

[makitso]

webtrees-noreply@skatekey.net

Might it be using the administrator email address?

[makitso]

OK, sequence looks like this. Visitor registered Visitor acknowledged email I went in and updated their user profile to approved. webtrees sent email to visitor BUT, it was rejected by email system. The email headers are listed below. Note the return path.

--TIGERTECH-BOUNDARY-1549378992-7714 Content-Description: Undelivered Message Content-Type: message/rfc822

Return-Path: makitso@gmail.com Received: from web05.tigertech.net (web05.tigertech.net [208.80.4.105]) by maila2.tigertech.net (Postfix) with ESMTP id 43v79D6ZWjz1T7hy for yloduckie@gmail.com; Tue, 5 Feb 2019 07:02:40 -0800 (PST) Received: by web05.tigertech.net (Postfix, from userid 17719) id 43v79D6S7Xz58pRH; Tue, 5 Feb 2019 07:02:40 -0800 (PST) Received: from www.skatekey.net (localhost [127.0.0.1]) by web05.tigertech.net (Postfix) with SMTP id 43v79D6MyGz58pRD for yloduckie@gmail.com; Tue, 5 Feb 2019 07:02:40 -0800 (PST) Message-ID: 712bee03359bd33def823c693db65d33@www.skatekey.net Date: Tue, 05 Feb 2019 15:02:40 +0000 Subject: New user at https://www.skatekey.net/ From: Rob Peters makitso@gmail.com Reply-To: Rob Peters makitso@gmail.com To: Janice Peters yloduckie@gmail.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_=_swift_1549378960574a517e72162e932e2b084068c8b1c8=_"

--_=_swift_1549378960574a517e72162e932e2b084068c8b1c8=_ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable

?=3D I18N::translate('Hello %s=E2=80=A6', e($user->realName())) ?>

The administrator at the webtrees site https://www.skatekey.net/ has approv= ed your application for an account. You may now sign in by accessing the fo= llowing link: https://www.skatekey.net/

--_=_swift_1549378960574a517e72162e932e2b084068c8b1c8=_ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hello Janice Peters=E2=80=A6

The administrator at the webtrees site https://www.skatekey.net/ has ap= proved your application for an account. You may now sign in by accessing th= e following link: https://www.skatekey.net/

--_=_swift_1549378960574a517e72162e932e2b084068c8b1c8=_--

--TIGERTECH-BOUNDARY-1549378992-7714--

[fisharebest]

The first email is sent out like this:

        Mail::send(
            new TreeUser($tree),
            $user,
            new TreeUser($tree),
            I18N::translate('Your registration at %s', WT_BASE_URL),
            view('emails/register-user-text', ['user' => $user]),
            view('emails/register-user-html', ['user' => $user])
        );

The first three parameters are "From", "To" and "Reply-to". A TreeUser is a dummy user (name and email) created from a tree.

The second email is sent out like this:

            Mail::send(
                Auth::user(),
                $edit_user,
                Auth::user(),
                /* I18N: %s is a server name/URL */
                I18N::translate('New user at %s', WT_BASE_URL),
                view('emails/approve-user-text', ['user' => $edit_user, 'site_url' => WT_BASE_URL]),
                view('emails/approve-user-html', ['user' => $edit_user, 'site_url' => WT_BASE_URL])
            );

Here, Auth::user() is you - the admin.

This one is sent from you, so that your users can reply to it.

If I understand you correctly, your SMTP server is rejecting this email, because the "From:" isn't actually the real sender.

Who else can we send this email from? We can't use the "current tree", as the user-admin page doesn't have a "current tree" (unlike the registration page - which does).

Perhaps we need to add a SiteUser object (see #2167) that is not linked to any tree. It might also let us add registration and password-resets to sites where all trees are private....

[makitso]

If I understand you correctly, your SMTP server is rejecting this email, because the "From:" isn't actually the real sender.

That is correct. I would think this is a standard security issue for ISP's? Why not use the same From: as the first Registration email?

[makitso]

I had a problem with the 2.0 email setup, I was using SMTP instead of Sendmail. I corrected this a few days ago and now emails are coming through fine. However, with this problem I was not getting any emails from my ISP noting the problem. Point is, people were not getting notified that they had been approved for access to my site.

[fisharebest]

Why not use the same From: as the first Registration email?

The first email was sent from the contact address for the tree. You can have many trees, each with different contact addresses. We used the tree that the visitor was viewing at the time they registered.

When you approve the account - which triggers the second email - we don't know which tree that was and hence which contact address to re-use.

Also, once you've approved them, it is safe to expose your email address to the new user.

[makitso]

Each tree has an element WEBTREES_EMAIL that is set to webtrees-noreply@skatekey.net as opposed to SMTP_FROM_NAME in wt_site_settings. IMHO, the approved email should follow the same logic as the registration email and use the webtrees-noreply@ . SMTP_HELO.

[makitso]

And, it goes without saying that sending an email with a Return Path of a different domain is a security problem.

And, that it opens up the possibility of a recipients SPAM filters rejecting it.

[fisharebest]

The workflow (as inherited from PGV) is that each tree has one genealogy contact, and the site has one or more administrators.

The new-user requests go to the genealogy contact. The genealogy contact then decides whether to approve the user. They genealogy contact then instructs one of the administrators to actually make the update.

In the PGV world, genealogy contacts are not (necessarily) administrators.

In your site (and the vast majority), there is only one administrator - who is also the genealogy contact for every tree.

Any changes to this workflow would be a backwards-compatibility break.