Mail blocked due to missing "To:" header

[xrat]

Mail messages sent by our DokuWiki installations sometimes are rejected with the error message

554 5.5.1 Error: no valid recipients

which is due to the fact that DokuWiki generated messages for e.g. subscribers are sent without "To:" header. Changing

$mail->bcc($subscriber_mail);

in function send of class Subscription in inc/subscription.php (line 603 in 2015-08-10a "Detritus") to

$mail->to($subscriber_mail);

fixes this (at least for us).
Why is DokuWiki using BCC instead of To?

[splitbrain]

$subscriber_mail can be a list of receivers. Mail-Addresses should not be leaked to other subscribers, that's why we use BCC here. I created a pull request #1428 that should fix your problem. Can you please try the change and report back?

[xrat]

Hi @splitbrain, thanks for the explanation. Of course, we should not disclose other subscribers. I have tested pull request #1428, and quite to my surprise I ran into serious troubles since our mail server is using Sendmail 8 which returns undisclosed-recipients:;... List:; syntax illegal for recipient addresses.
After extensive research I'd like to suggest NOT to include the pull request. In fact, it seems it is recommended that DokuWiki is remained unchanged.

I have contacted colleagues and posted a question at serverfault.com. I plan to provide more details here as I receive them. What I got so far:

• To: undisclosed-recipients:; is a legal form of group address according to RFC 5322.
• Sendmail does not support empty RFC 5322 group addresses when submitting via sendmail -t (which is the default on *nix for PHP), see also my [question at serverfault.com].
• Omitting To: is valid practice according to RFC 5322. The To: header is optional (cf. RFC 5322, Secion 3.6. Mail server admins who reject messages that lack To: should be instructed accordingly. (Of course, if the problem is wide-spread, DokuWiki maintainers might consider a workaround, however, I think this type of rejection is rare.)
• Personally, I like To: undisclosed-recipients:; because it clearly states what is actually the case. I have tested various possible alternatives using Sendmail and Postfix. The most reasonable one that worked in all cases was suggested 2003 by no less than Wietse Venema: To: (undisclosed recipients). This "trick" uses a so-called "(comment)". However, RFC 5322 states that comments "SHOULD NOT be used."

Please accept my sincere apologies for the confusion and the perhaps rather futile bug report. Worth considering, though:

• Does DokuWiki generate an empty To: header? My tests on Sendmail and Postfix show an empty To: header on the receiving end. Perhaps DokuWiki should not generate To: at all (if recipients are only in Bcc:)?
• There are 2 proper ways to fix issues like these altogether:
  1. Use SMTP instead of sendmail -t (this is what many other PHP applications resort to).
  2. Generate 1 message per recipient and put the recipient in To:.

Edit 2015-12-16 22:43: Apparently, Sendmail does support group addresses, just not empty ones like group:;.

[splitbrain]

@xrat thanks for the research, please keep us updated.

DokuWiki should not generate an empty To: header. I think we even have tests for that.

SMTP can be used with the SMTP plugin but is beyond the scope of this ticket.

Generating individual messages would probably be a good idea. In fact I think this is the case for most cases already. The only time I can think of where multiple addresses are passed is when you put a comma separated list in $conf['notify'], but I might be wrong. This would need research.

[xrat]

DokuWiki does generate an empty To: header (tested with Release 2015-08-10a "Detritus" on PHP version 5.6.14-0+deb8u1). According to RFC 5322 Secion 3.6.3 the To: should or even must not be empty. However, I very much doubt that any current mail server would reject messages on these grounds. Yet, my recommendation is to make it non-empty or leave it off completely.

The operator of the mail server that rejected our DokuWiki notifications informed us that the rejections were actually caused by issues with a broken MySQL database and were not based on the mail server's configuration. Consequently, DokuWiki notifications are accepted again. No patches required.

I haven't received any answer for my Sendmail inquiry regarding support for empty groups such as undisclosed recipients:;. Also, I expect not to get any answer anytime soon. In fact, I have further researched the matter myself: To solve this properly in Sendmail requires a change of the program's source code to make it ignore empty groups.

Concluding:

• The initial issue of this ticket was not related to DokuWiki.
• To add a To: undisclosed-recipients:; header when To: would otherwise be empty is not recommended as it would break delivery at least on *nix servers running Sendmail.
• Leaving off an empty To: altogether seems slightly favorable.
• In the long run, I'd recommend that DokuWiki generates individual message with the recipients address shown in To:, possibly including a full name which should help pass spam filters even more.

[cschramm]

The source of the empty header field is not Dokuwiki itself but the the way Dokuwiki and PHP interact.

mail("", "S", "", ["Bcc" => "B"]) passes

To: 
Subject: S
Bcc: B

to sendmail.

Its documentation thus specifies

The formatting of this string must comply with » RFC 2822.

for the first parameter and the RFC requires at least one address (mailbox or group) for "To: ". (PHP missed that the Internet uses RFC 5322 nowdays, but that makes no difference.)

It's an error that Dokuwiki passes an empty value to the mail function and I see providers rejecting its notification emails because of that. 😞

#1428 would be awesome to get this fixed.

[Klap-in]

@cschramm are you opposing the proposal of @xrat above #1422 (comment)? Sending messages separately looks more robust than the 'undisclosed-recipients:' quick fix.

[cschramm]

@Klap-in: That'd work fine as well, yes.

[mschlenstedt]

I have the same error: emails still are send with empty to:

Any news on this topic?

[wekev]

@splitbrain: I've got the same problem with an empty "to:" Parameter but fix it in our installation.

To be flexible for the different configurations, here is my idea for a fix.

1. Add an Config-Parameter to define a default "to:" parameter, if no one is set (e.g. maildefaultto)
2. Add the following lines in Mailer.class.php at line 765 (of Igor Version):
   if (empty($to) && !empty($conf['maildefaultto']))
   $to = $conf['mailforceto'];

Depending of the mail system and behave of the user it is possible to use 'undisclosed-recipients:;' or define the sender Mail address, which i see in some Newsletters like to:noreply@example.com (by the way, in the newsletters are valid Mail addresses used not example.com ;-)

The default should be an empty maildefaultto, therefore nothing changed in general.
If the mail system needs a "to:" address, the user is able to configure a valid mail address or the 'undisclosed-recipients:;'.

(Edited for better reading ;-)

[splitbrain]

Some update on this. I just encountered a similar problem on my local dev machine where I am running mailhog as MTA (see https://www.splitbrain.org/blog/2022-05/03-mailhog_as_default_mta).

Mailhog complained:

Mar 11 12:22:07 rumpel mailhog[460]: 2023/03/11 12:22:07 [SMTP [::1]:34978] Received 12 bytes: 'RCPT TO:<>\r\n'
Mar 11 12:22:07 rumpel mailhog[460]: 2023/03/11 12:22:07 [SMTP [::1]:34978] [PROTO: RCPT] Processing line: RCPT TO:<>
Mar 11 12:22:07 rumpel mailhog[460]: 2023/03/11 12:22:07 [SMTP [::1]:34978] [PROTO: RCPT] In state 7, got command 'RCPT', args 'TO:<>'
Mar 11 12:22:07 rumpel mailhog[460]: 2023/03/11 12:22:07 [SMTP [::1]:34978] [PROTO: RCPT] In RCPT state
Mar 11 12:22:07 rumpel mailhog[460]: 2023/03/11 12:22:07 [SMTP [::1]:34978] [PROTO: RCPT] Got RCPT command
Mar 11 12:22:07 rumpel mailhog[460]: 2023/03/11 12:22:07 [SMTP [::1]:34978] Sent 36 bytes: '550 Invalid syntax in RCPT command\r\n'

This had worked in previous (php 7) setups, so I assume this is another PHP8 change. It seems PHP8 will not omit the To: header anymore when it is set to an empty string. Setting $to to null fixed the problem. I will check if this also works with PHP7 and will add the fix on top of #3831. Nevermind, my mistake. null behaves the same.

This is slightly related to #3768 and #3733

[splitbrain]

@xrat https://serverfault.com/a/758337 suggests to use the round parentheses as work-around for sendmail. Eg. specifying a To: header that only has a display name but no address.

In my tests at dokuwiki.org (running postfix) and on my local machine (running mailhog) this worked fine. It would be helpful if everyone involved in this thread could add the following line

if($to === '') $to = '(undisclosed-recipients)';

Put it right above above the mail sending here:

dokuwiki/inc/Mailer.class.php

Lines 769 to 773 in 78b498a

	if($this->sendparam === null) {
	$success = @mail($to, $subject, $body, $headers);
	} else {
	$success = @mail($to, $subject, $body, $headers, $this->sendparam);
	}

Please report back if this works for you and which MTA you are using. I would be especially interested in Exim, MS Exchange and Sendmail.

[wekev]

@splitbrain: I've testet your code and it works fine with Sendmail on a Windows machine.

[xrat]

I have tested "(undisclosed-recipients)" on 2 systems, both Debian 11 w/ FPM-PHP 7.4 with a total of 3 DokuWikis, all v2022-07-31 "Igor". As MUAs I used Alpine 2.24, Mutt 2.0.5, Thunderbird 102.8 and less ;-)

• System 1: Postfix 3.5.17, Courier-IMAP 5.0.13, Maildir storage, procmail as MDA, sendmail_path set to use msmtp.
• System 2: Sendmail 8.15.2, Dovecot 2.3.13, mbox storage, procmail as MDA, sendmail_path not set.

No problems found at all.

Thunderbird's "Reply All" function does not know how to handle "(undisclosed-recipients)". But, that's probably no big issue. And its not DokuWiki's fault.

[alexanderbeermann]

I am facing this issue as well. My Dokuwiki instance is running on a HostEurope WebPackage. They are using exim 4.92 as a MTA. This Setup was running very smoothly for several years. Do you have any Idea what ist the root-cause that Mails (without TO)are blocked for two weeks now?

[xrat]

I did some quick testing using an Exim 4.94.2 providing a message via SMTP with no "To:", with an empty one and with "To: (undisclosed-recipients)". All 3 messages were accepted and forwarded.

[tomabrafix]

Unfortunately, some recipients (especially mailing lists) do not accept mails if the recipient is not listed in the To:. It would be better if each recipient would receive its own mail with matching To-Header.