in reply to E-Mail responder

From the sendmail FAQ, the following may or may not help explain the issue:

With no flags, sendmail reads its standard input up to an end-of-file or a line consisting only of a single dot and sends a copy of the message found there to all of the addresses listed. It determines the network(s) to use based on the syntax and contents of the addresses.

Local addresses are looked up in a file and aliased appropriately. Aliasing can be prevented by preceding the address with a backslash. Normally the sender is not included in any alias expansions, e.g., if `john' sends to `group', and `group' includes `john' in the expansion, then the letter will not be delivered to `john'.

-t Read message for recipients. To:, Cc:, and Bcc: lines will be scanned for recipient addresses. The Bcc: line will be deleted before transmission. Any addresses in the argument list will be suppressed, that is, they will not receive copies even if listed in the message header.

This doesn't really make it clear to me why -t is dangerous or why you'd be getting an error, however. What error are you getting?

EDIT: Hah, we all missed the obvious and tilly found it :)

Replies are listed 'Best First'.
Re^2: E-Mail responder
by good2cu (Initiate) on Nov 28, 2005 at 12:26 UTC
    Thanks for your response.
    I don't understand why the -T switch might be dangerous either. The ISP says
    "It has come to our attention that one of the scripts on your site is spamming AOL users: /secure/s/a/n/santastefano.com/cgibin/demo.pl This is causing AOL to block legitimate emails originating from our servers. We strongly recommend that you update your script to prevent this. The script has been disabled until it is updated. Some guidelines for updating this can be found below: For Perl/CGI users: Although it is very handy to be able to use the "-t" switch with sendmail, these days it is opening yourself up to potential (and often very real) problems. Putting the "-t" switch onto the sendmail command line causes sendmail to read through the mail headers in order to determine the recipients. Usually, form variables are used to construct part of the headers, eg subject text, sender email address etc (ie these are printed into the email as part of the headers). Unless you are very careful, spammers can inject additional headers by putting newline characters into these form variables. This opens your script up to abuse. The answer is to not use the "-t" switch with sendmail. Instead, you need to supply the recipient email addresses on the sendmail command line. eg. Intead of doing this: # THIS IS BAD 
    $recip = 'fred@fred.com';<br>
$subject = $formvars{'subject'};<br>
open (MAIL, "| /usr/sbin/sendmail -t");<br>
print MAIL "To: $recip\r\n";<br>
print MAIL "From: Website Enquiry <>\r\n";<br>
print MAIL "Subject: $subject\r\n\r\n";<br>
print MAIL $message;<br>
close (MAIL);<br>

    [download]
    do this instead (the only difference is on the "open" line) # THIS IS GOOD <code>$recip = 'fred@fred.com';
    $subject = $formvars{'subject'};
    open (MAIL, "| /usr/sbin/sendmail $recip");
    print MAIL "To: $recip\r\n";
    print MAIL "From: Website Enquiry <>\r\n";
    print MAIL "Subject: $subject\r\n\r\n";
    print MAIL $message;
    close (MAIL);
    Additionally, do not allow $recip to be set from a form variable else a spammer will still be able to abuse it. Always hard code the recipient address into the script or in a configuration file. The error message I receive is "Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, root@cougar.dnsmaster.net and inform them of the time the error occurred, and anything you might have done that may have caused the error." I do not have access to the logs and have not received a response so far.
    More information about this error may be available in the server error log.
[reply]
[d/l]
      Since you get $subject from the form, a spammer can put a \n in the subject, and create an additional "to:" line. This is the source of the spam.

      Never take unchecked input and insert it into any part of a mail header.

      -- Randal L. Schwartz, Perl hacker
      Be sure to read my standard disclaimer if this is a reply.

[reply]
        Thanks.
        I am not very experienced in perl. I understand (I think) what you have said but can you give me a clue - pointer - as to how to check the input and avoid the problem? Best regards
[reply]
Re^2: E-Mail responder
by good2cu (Initiate) on Nov 28, 2005 at 09:12 UTC
    Many thanks, trying now.
[reply]

In Section Seekers of Perl Wisdom