Notes |
(0005015)
steffen (reporter)
2020-10-01 15:48
|
To reiterate what i said on the ML, i think this would be a sensible addition because POSIX mailx allows creation of Bcc: headers via the ~b and ~h command escapes as well as via the askbcc internal variable. |
|
(0005018)
geoffclare (manager)
2020-10-02 13:59
|
I'm struggling to understand why any user would want to set this variable. What would they gain from it? Whatever benefit it is, it would need to be weighed against the risk of a Bcc not being stripped if the MTA is later changed (by a system administrator) to one that doesn't strip it. (Or do you expect them to check that the MTA hasn't changed every time they send an email with an embarrassing-if-leaked Bcc?)
As regards adding it to the standard, there is the problem of how would a user decide whether it is safe to set it. We would have to require that the system documentation provides enough information for users to be able to decide. And if the system has multiple MTAs available, the documentation would naturally provide the relevant info for each one, necessitating that the user somehow work out which MTA is installed (or if multiple MTAs are installed, which one mailx will use). |
|
(0005019)
steffen (reporter)
2020-10-02 21:51
|
But .. first: as of today all mailx codebases known to me (that i looked into the last couple of years) except mine pass the readily prepared message through as-is. This potentially includes Bcc headers if they were generated.
Remark: it is not only embarrassing-if-leaked, but many people of the free software world work for a very large free mail provider and due to the smartness of their system they easily "detected" that i have created multiple accounts a decade ago, and if suddenly the name of the one account happens to appear as a injection in visible headers of messages sent via another account, then this is not _only_ embarassing, but .. very funny! Heartbleed here.
Of course, "my" MUA has a complete "infrastructure" to allow users to specify the actually used MTA, and in this context the variable as such makes sense.
It would be nice if POSIX would support it, but like i said on the ML
Important would be an equivalence to or some words about the
*mta-bcc-ok* setting of my one, since POSIX mailx supports Bcc:
via ~b, ~h and *askbcc*:
For completeness sake, we support a complete "infrastructure":
mta Select an alternate Mail-Transfer-Agent by either specifying the
full pathname of an executable (a ‘file://’ prefix may be given),
or [Option]ally a SMTP aka SUBMISSION protocol URL:
...lots of text...
mta-arguments
Arguments to pass through to a file-based mta[473] (Mail-Transfer-
Agent), parsed according to Shell-style argument quoting[23] into
an array of arguments which will be joined onto MTA options from
other sources, for example ‘? set mta-arguments='-t -X "/tmp/my
log"'’.
Even if POSIX would offer configuration of the actually used (file-based) MTA, this one here requires a (more or less) complete (and correct) shell-style parser, which is not an easy task.
mta-no-default-arguments
(Boolean) Avoids passing standard command line options to a file-
based mta[473] (please see there).
mta-no-receiver-arguments
(Boolean) By default all receiver addresses will be passed as com‐
mand line options to a file-based mta[473]. Setting this variable
disables this behaviour to aid those MTAs which employ special
treatment of such arguments. Doing so can make it necessary to
pass a -t via mta-arguments[475], to testify the MTA that it should
use the passed message as a template.
mta-argv0
Many systems use a so-called mailwrapper(8)[728] environment to
ensure compatibility with sendmail(1)[729]. This works by inspect‐
ing the name that was used to invoke the mail delivery system. If
this variable is set then the mailwrapper (the program that is
actually executed when calling the file-based mta[473]) will treat
its contents as that name.
mta-bcc-ok
(Boolean) In violation of RFC 5322 some MTAs do not remove ‘Bcc:’
header lines from transported messages after having noted the
respective receivers for addressing purposes. (The MTAs Exim and
Courier for example require the command line option -t to enforce
removal.) Setting this variable asserts that the MTA performs
stripping.
(Maybe i can add a word of description for my MUA here.)
All mailx codebases i know have to duplicate the entire message in order to filter out the Bcc line when passing messages through to the MTA.
It can be made a bit simpler for less feature-rich implementations which do not support signing etc., however, they could just call puthead() without GBCC set,
And it has to be said that many mailx codebases support the internal variable "sendmail" instead of our mta like so
if ((cp = value("sendmail")) != NOSTR)
cp = _PATH_SENDMAIL;
(Research Unix v10 uses MAIL as a fallback, which is "/bin/mail".) |
|
(0005020)
steffen (reporter)
2020-10-02 21:53
|
I said
It can be made a bit simpler for less feature-rich implementations which do not support signing etc., however, they could just call puthead() without GBCC set,
I have not actually tried it, but .. i think this should do it. |
|
(0005021)
steffen (reporter)
2020-10-02 22:14
|
(However, for *record* the full message has to be produced...) |
|
(0005024)
geoffclare (manager)
2020-10-05 08:22
|
Perhaps the most appropriate solution would be for POSIX simply to state that Bcc is not included in the message that the "mail delivery system" (as it calls the MTA) delivers, and leave how this is achieved up to the implementation. |
|
(0005028)
steffen (reporter)
2020-10-05 17:30
|
Ok, how about that.
On page 2948, append after line 97657 )
When the message is typed and the end of the message is encountered, the message shall be passed to the mail delivery software.
)
The list of blind carbon copy (Bcc) recipients shall not be included as part of the generated message. |
|
(0005029)
steffen (reporter)
2020-10-05 17:32
|
P.S.: maybe instead "but shall be passed by other means [not covered by this specification]".
P.P.S.: sorry for the false parenthesis. |
|
(0005031)
steffen (reporter)
2020-10-05 21:50
|
But maybe you are right and this is just beyond the standard, and this issue should be closed as invalid.
It surely is a fault of MTAs aka mail delivery software, unfortunately it is real behaviour of (at least) two widely deployed POSIX/Unix programs around (of the four that i would count as big ones), and this not only affects mailx but also other mail user agents (including the one you, Geoff Clare, use).
Distributions patch(ed) some software to work around this, but applications also get regulary patched/changed to allow dealing with the situation lately.
The behaviour as such is in the world for many years.
Hm.
Maybe instead of the above a word a sentence like
The mail delivery software shall interpret passed messages according to the rules of RFC 5322.
would be an acceptable way to deal with the situation?
RFC 5322 is very clear (as all standards before were if i recall correctly), and has a discussion in the "Security considerations" section, too:
Many implementations use the "Bcc:" (blind carbon copy) field,
described in section 3.6.3, to facilitate sending messages to
recipients without revealing the addresses of one or more of the
addressees to the other recipients. Mishandling this use of "Bcc:"
may disclose confidential information that could eventually lead to
security problems through knowledge of even the existence of a
particular mail address.
Good night. |
|
(0005237)
geoffclare (manager)
2021-02-15 16:40
edited on: 2021-02-15 16:41
|
On page 2943 after line 97448 append the following:The message shall be passed to the mail delivery software. The mail delivery software shall process passed messages according to the rules of IETF RFC 5322.
|
|