It was originally my intent to put all recipients in the Bcc: header and use the -t option. But then I read in RFC 2822, “Internet Message Format”, (http://www.faqs.org/rfcs/rfc2822.html) the following:

— begin quote —

Section 3.6.3 Destination address fields

[snip] There are three ways in which the “Bcc:” field is used. [snip] In the second case, recipients specified in the “To:” and “Cc:” lines each are sent a copy of the message with the “Bcc:” line removed as above, but the recipients on the “Bcc:” line get a separate copy of the message containing a “Bcc:” line. [snip] Which method to use with “Bcc:” fields is implementation dependent [snip].

[snip]

Section 5. Security Considerations

[snip] When the second method from section 3.6.3 is used, the blind recipient’s address appears in the “Bcc:” field of a separate copy of the message. If the “Bcc:” field sent contains all of the blind addresses, all of the “Bcc:” recipients will be seen by each “Bcc:” recipient.

Yes, I’ve seen that the “Bcc:” line is removed by the SMTP program that is installed at DreamHost (I think it’s PostFix).

But the standard indicates that other implementations have the option to include the “Bcc:” line (with all the “Bcc:” recipient addresses) in the copies of the message that are sent to the “Bcc:” recipients.

Therefore, it seems that using the “Bcc:” header is not a portable method. Do you agree?

I will have to read it over again, but I believe you’re misunderstanding the RFC. If the Bcc: header were included, it wouldn’t really be Bcc, now would it.

Ok, gave that a quick read. I don’t believe that any system commonly used implements the second way of doing things… Almost certainly The Real Sendmail (as seen in my example) and Postfix both do things the first way.

I think in the interests of simplicity, it will be better to use the “Bcc:” header.

The standard states (in Section 3.4.) that in a group construct, destination headers may be followed by “any number” of mailboxes. Presumably, this applies also to an address list that is not part of a group construct.

Thus, the only question is how to format the list of addresses (as you indicated above) such that they do not exceed the 78 character recommended line length (and/or the 1000 character hard length limit).

Because sendmail reads the message file from the standard input, any questions of memory buffers for the command line are completely avoided.

If you put user data on the To: line, and use the -t flag, what checks should be made to a user-supplied email address to avoid nasty problems?

This probably doesn’t cover all possible exploits -

You should strip out characters less than 32 ASCII when any user-supplied input is going to appear in the message headers. That will keep the user from adding message headers of his own. Here’s an example that converts tabs to space and removes LF and CR’s in Perl (untested, you’re not going to learn if i do the work for you)