Config return address on PGV-generated mail?

Help
ggpauly
2012-08-24
2013-05-30
  • ggpauly
    ggpauly
    2012-08-24

    Couldn't find this in the forum archives -

    is there a way to change the return address for mail sent to admins from PGV?

    One of my ISPs no longer sends website-generated mail except with a "from" address with the website domain.   When using the "Contact Admin" web form, PGV puts the address of the person filling the form in the "from" address, and the mail now gets bounced.  There are a lot of PGV sites at this ISP, so others will be affected, although they may not realize it yet.

    This behavior always struck me as a bit unusual, possibly confusing, however now it's harmful.

    Note that the "PhpGedView reply address" edit Gedcom Contact Information config only partially addresses this - this sets the return for mail going back to the user filling out the contact form, not the return for mail going to the admin (although maybe it should set both).

    Thanks,

    George

     
  • Stephen Arnold
    Stephen Arnold
    2012-08-24

    George
    Hardly is this

    behavior…a bit unusual, possibly confusing,

    It serves the purpose precisely as designed. Usually, an admin needs to communicate via email with the sending party. Using the sender's information as the From address allows a quick reply to the right location - no searching, cutting and pasting. It makes the recipient's email address secure (avoids spam) yet acts as a simple pass-through.

    To vary this action, you will need to modify the code. IIRC, this is controlled in the "authentication.php" file.
    Strange that your ISP has chosen to ignore normal mail handling methods of looking at the RETURN-PATH and RECEIVED FROM header information which gives a much record of the mail origination.
    -Stephen

     
  • ggpauly
    ggpauly
    2012-08-24

    Hardly is this

    behavior…a bit unusual, possibly confusing,

    I found it unusual & perhaps the first time it happened a bit confusing to receive an email from the webserver marked as from the submitter's email address.  It's a little weird because it looks like the email is coming directly from the submitter, rather than through a web form.  I've programmed several web forms and I've never done this.  The email address entered into the form is usually included in the body of the message.  It's possible my expectations are unusual because of my programming experience, however I've never encountered this behavior elsewhere.

    The reason for this as stated by the ISP is that this behavior can be used for evil: web generated messages with faked from addresses can be generated this way for the purpose of theft by deception.  Email providers blacklist misbehaving ISPs, and  my ISP wishes to clean up their record.  This seems perfectly reasonable to me.  I have little or no control over their decisions and this one seems more reasonable than some they've made lately.  I've complained and they've responded.  As I said, this will affect many PGV installations besides mine at this ISP, and this may be a trend among ISPs. 

    I'll work on a patch, and if it will be accepted by PGV I'll work with PGV on the details. 

    The details are the behavior.  I'd be happy to just have is use the same from: address as mail sent to the user.  The email address of the form submitter is redundantly included with the message, so no other change is needed.

    George

     
  • Gerry Kroll
    Gerry Kroll
    2012-08-24

    George:
    I think PGV's current behaviour is quite logical.  An e-mail generated through the web form and addressed to the admin actually DOES come from the user filling out the form.  The only differences between a normal e-mail and the web form are the software used to create the e-mail and the server used to send the message.  It's still a message from the user to the admin.

    I don't see how this can be fixed without breaking it for someone else. 

    It's not reasonable for the ISP to expect everyone to have a valid e-mail address in the same domain that hosts PGV.  However, it IS reasonable to demand that the reply-to address is legitimate.  The legitimacy test should be limited to detecting addresses to which mail can't be delivered.

    Instead of messing with PGV's code, you need to negotiate with the ISP for a more reasonable approach to e-mails generated by PHP programs.  In other words, instead of modifying several dozen programs, not all of which are PhpGedView, the "fix" (if you really want to call it that) needs to be applied higher up the food chain.

     
  • ggpauly
    ggpauly
    2012-08-24

    Hi, Thanks for the reply,

    My ISP has been working on this for several months.  They rolled back the change in April after complaints, and now they're implementing it again.  This is a large ISP recently bought out by an even larger ISP.  I've put my 2 cents in, and for better or worse it's been made clear to me that even bigger fish (like Gmail) are behind this requirement in that they may blacklist ISPs that don't enforce it.  It's non-negotiable, a done deal.

    This is not about PGV.  It's about any web software generating emails.  The ISP can't review every piece of code to make sure it's behaving nicely and not trying to trick someone.  PGV's code seems safe:  it's easy to write similar code that can be used by criminals. 

    This has and will screw up many PGV sites unless it's fixed.

    Likely there are other programs out there that will need to be fixed - that's probably why the initial rollback happened in April.  I think this change will happen, and all web hosting ISPs will eventually be forced to implement it as the criminals move to unprotected systems and hurt their reputation. 

    Regards,

    George

     
  • Stephen Arnold
    Stephen Arnold
    2012-08-24

    George
    The prohibition of 'relaying' has been in place for some time. PGV carefully crafted its use of standard php form mailing to prevent spamming of the admin by discovering email addresses and it skillful developed a function that prevented relaying.
    Open relays are the scourge of the net and it is one of the primary reasons most broadband providers blocked Port 25. Many worms were developed to attack PCs and then open relaying through their attachments.

    There is actually better security in allowing PGV to send an email via its pass-through programming than to solicit direct email addy to email addy communications. It can block attachments and discourage worms and virus attacks.  As I said, your ISP has used a flawed analysis of the risks to the possibility of blacklisting as an excuse to reduce their own expense and limit their users.  I would suggest you find a new host if the change at your provider is written in concrete.
    -Stephen

     
  • ggpauly
    ggpauly
    2012-08-25

    As I said, it's not about the carefully crafted PGV code.  It's about how website scripts can be used to trick people by falsifying email headers.  You can put your head in the sand about this, but it's going to hurt a lot of PGV users.

     
  • Gerry Kroll
    Gerry Kroll
    2012-08-25

    George:
    Please explain EXACTLY which "contact the admin" link we're dealing with.

    If you're talking about the "contact" link that appears at the bottom of every page, there's a very simple solution.  Just edit the GEDCOM configuration, "Contact" section.  Change the contact methods to "Mailto link".  This change will cause the browser to launch the user's e-mail client so that the e-mail is sent through the user's regular e-mail server.

    Right now, this Mailto link doesn't pre-load the e-mail's subject line.  That can be fixed easily so that the resultant e-mail doesn't start out with an empty subject.

     
  • ggpauly
    ggpauly
    2012-08-27

    Thanks,

    Yes that's the link I'm talking about.

    The "mailto:" suggestion is helpful, and may be sufficient depending on how widespread this turns out to be.  It's a workaround though, not a solution.  If someone who's ISP implements this policy is using or wants to use the form for contact they're going to have problems.  Also, I think there are other situations such as change approvals, new users, perhaps others, that may generate admin email - I haven't investigated these other cases.  The mailto: would not likely apply to these if they indeed have the problem.

    Regards,

    George

     
  • Gerry Kroll
    Gerry Kroll
    2012-08-27

    George:
    That form only does bad things on your site when the contact method is "Internal messaging with e-mails".  Just disable or remove that option if you're so worried about it.

    I don't think there are any other places in PGV where the program pretends to originate an e-mail from somebody other than itself or the admin.  The program-generated e-mails are already covered by the GEDCOM configuration option.

    If the admin's e-mail address is in a domain other than that anal-retentive ISP's, there isn't a damn thing that can be done.  You're just not going to get any support for fixing this ISP problem.  As Stephen has already told you - find a more "with it" ISP.

     
  • ggpauly
    ggpauly
    2012-08-30

    Gerry.

    What did you mean in post #4 above :

    I don't see how this can be fixed without breaking it for someone else.

    ?

    The only change I see is that the admin can't respond to the email by replying to it.  

    Instead, to reply, the admin must initiate a new email using the address in the body of the email she received.

    Is this what is meant by "breaking it ", or am I missing something?

    Thanks,

    George

     
  • Gerry Kroll
    Gerry Kroll
    2012-08-31

    It'sbetter to configure PGV's contact methods for "mailto".

    However, if you're going to "fix" the ISP's problem by changing the PGV code - go ahead.  If your changes make sense, they'll be adopted into the SVN repository.

    I think it's almost time to get John to update the download page to reflect the current SVN.