Skip to main content

php mail() error: Undefined subroutine &main::maskdir

Comments

6 comments

  • g-force
    A client of mine notified me that all emails sent from PHP were failing. After investigation, I found I had the same error as above. I tried the following : /scripts/upcp --force /scripts/buildeximconf service exim restart It didn't work, so I changed the line 1132 in the file /etc/exim.pl from : my $xsourcedir = maskdir($ENV{'X-SOURCE-DIR'}); To : my $xsourcedir = $ENV{'X-SOURCE-DIR'}; After restarting exim, PHP was able to start sending emails again. Can someone from cPanele explain what caused this problem and how to prevent it in the future?
    0
  • Jim Huang
    what is that maskdir even nothing comes up in google so strange?
    0
  • hamadino
    I got the same problem. I changed the line 1132 in the file /etc/exim.pl from : my $xsourcedir = maskdir($ENV{'X-SOURCE-DIR'}); To : my $xsourcedir = $ENV{'X-SOURCE-DIR'}; Thank you g-force Waiting for cPanel explanation or work around
    0
  • cPanelMichael
    Hello, It's possible this is related to the issue reported on the following thread: Email stopped working after update Could anyone experiencing this issue review that thread and let us know if the solution addresses the issue with sending out emails via PHP? Thank you.
    0
  • santrix
    This doesn't appear to relate to the exim.pl permissions bug to which cPanelMichael refers. We have now found that the Tweak Settings > Mail > "Track email origin via X-Source email headers", when enabled, immediately causes messages like this in exim_mainlog:
    2016-06-09 09:15:39 1bAv7q-000bDV-CM == redacted@redacted.com R=dkim_lookuphost defer (-1): dkim_lookuphost router failed to expand add_headers item "NULL": Undefined subroutine &main::maskdir called at /etc/exim.pl line 1132.\n 2016-06-09 09:15:44 H=([x.x.x.x]) [x.x.x.x]:24865 I=[x.x.x.x]:25 sender verify defer for : dkim_lookuphost router failed to expand add_headers item "NULL": Undefined subroutine &main::maskdir called at /etc/exim.pl line 1132.
    Disabling this option makes the problem go away. We are seeing this beahaviour on dozens of servers, running CloudLinux 6 and 7 and cPanel v56.22. We have not yet opened a support request with cPanel.
    0
  • cPanelMichael
    New This doesn't appear to relate to the exim.pl permissions bug to which cPanelMichael refers.

    Were you able to verify the permissions for the /etc/exim.pl file on the affected systems? You can do so with a command such as:
    stat /etc/exim.pl
    Thank you.
    0

Please sign in to leave a comment.