Matthieu Moy <> writes:

>>> If it's not in the body of the message, then where is it?
>> This point is clarified in the thread
>>, which is
>> with my upstream maintainer.
> Which explicitly states that the syntax is not [$number], but # $number,
> right?

But I do not think that works, either.  Let's step back.

People write things like these

    Cc: Stable <> # 4.8
    Cc: Stable <> [4.8+]

in the trailer part in the body of the message.  Are these lines
meant to be usable if they appear as Cc: headers of an outgoing
piece of e-mail as-is?

That question has two subissues.

 * Are these RFC compliant?
 * Do real-world servers accept them?

I did a quick test with my e-mail provider, by sending a test
message with the above (with <> replaced with
my address, of course) on Cc: and the answer to the second question
appears to be no.

When I send the former, I get this:

    550 5.1.1 <4.8>: Recipient address rejected: User unknown...'
    errormsg='recipient address 4.8 not accepted by the server'

The latter gives me this:

    550 5.1.1 <[4.8+]>: Recipient address rejected: User unknown...'
    errormsg='recipient address 4.8 not accepted by the server'

So even if these were accepted by some servers, it is not sane
to assume that these lines are meant to be copied to Cc: headers
when sending out.  "send-email --cc" needs to salvage these
malformed lines.

For me, it seems that I get correct envelope rcpt-to addresses for
both of them (i.e. "" and nothing else appears
on the command line of sendmail invocation), even though I seem to
get a strange Cc: that are visible to humans:

    Cc: "Stable # 4 . 8" <>,
        "Stable [4.8+]" <>

I seem to have libmailtools-perl 2.12 on my system.

Just like Peff who tried to disable Mail::Address, it seems that
I get complaint on both of them.

"error: unable to extract a valid address from:" is followed by

    Stable <>
    Stable <[4.8+]>

which is not ideal.

If I were to issue a decree, I would say that people should stop
suggesting to put RFC-bogus things on the Cc: line.  As you
mentioned, things like:

    Cc: Stable (4.8+) <>
    Cc: "Stable 4.8+" <>

are perfectly readable alternative that are still RFC-kosher.

Things may have appeared to work by accident, and things may still
work by accident, depending on the vintage and availability of
Mail::Address package (which seems to be the case), but it is not
worth risking random breakages that depends on what other people
use in the first place, no?

That is, even though people seem to expect "send-email --cc" to
somehow be able to judge that " # 4.8" and " [4.8+]" are cruft not
meant as part of a valid address, I do not think it is a realistic
expectation.  How would it know "Cc: Stable <> 4.8, 4.9"
has garbage " 4.8, 4.9" that needs to be stripped, while "Cc: Stable
<> 4.8," has two valid
addresses that need to be CC'ed and " 4.8" is the only thing that is

I'd welcome to be proven wrong with a working patch that makes
"send-email --cc" to be hyper intelligent ;-), though.

Reply via email to