View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001408 | 1003.1(2016/18)/Issue7+TC2 | Shell and Utilities | public | 2020-09-30 20:48 | 2024-06-11 09:08 |
| Reporter | steffen | Assigned To | |||
| Priority | normal | Severity | Editorial | Type | Enhancement Request |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | steffen | ||||
| Organization | |||||
| User Reference | |||||
| Section | Vol. 3: Shell and Utilities, mailx | ||||
| Page Number | 2952 | ||||
| Line Number | 97836 | ||||
| Interp Status | --- | ||||
| Final Accepted Text | 0001408:0005237 | ||||
| Summary | 0001408: mailx: add mta-bcc-ok internal variable | ||||
| Description | My mailx clone (will) document(s) it like this: 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. | ||||
| Desired Action | Adapt an internal variable mta-bcc-ok, default unset. | ||||
| Tags | tc3-2008 | ||||
|
|
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. |
|
|
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). |
|
|
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".) |
|
|
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. |
|
|
(However, for *record* the full message has to be produced...) |
|
|
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. |
|
|
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. |
|
|
P.S.: maybe instead "but shall be passed by other means [not covered by this specification]". P.P.S.: sorry for the false parenthesis. |
|
|
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. |
|
|
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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-09-30 20:48 | steffen | New Issue | |
| 2020-09-30 20:48 | steffen | Name | => steffen |
| 2020-09-30 20:48 | steffen | Section | => Vol. 3: Shell and Utilities, mailx |
| 2020-09-30 20:48 | steffen | Page Number | => 2952 |
| 2020-09-30 20:48 | steffen | Line Number | => 97836 |
| 2020-10-01 15:48 | steffen | Note Added: 0005015 | |
| 2020-10-02 13:59 | geoffclare | Note Added: 0005018 | |
| 2020-10-02 21:51 | steffen | Note Added: 0005019 | |
| 2020-10-02 21:53 | steffen | Note Added: 0005020 | |
| 2020-10-02 22:14 | steffen | Note Added: 0005021 | |
| 2020-10-05 08:22 | geoffclare | Note Added: 0005024 | |
| 2020-10-05 17:30 | steffen | Note Added: 0005028 | |
| 2020-10-05 17:32 | steffen | Note Added: 0005029 | |
| 2020-10-05 21:50 | steffen | Note Added: 0005031 | |
| 2021-02-15 16:40 | geoffclare | Note Added: 0005237 | |
| 2021-02-15 16:41 | geoffclare | Note Edited: 0005237 | |
| 2021-02-15 16:41 | geoffclare | Interp Status | => --- |
| 2021-02-15 16:41 | geoffclare | Final Accepted Text | => 0001408:0005237 |
| 2021-02-15 16:41 | geoffclare | Status | New => Resolved |
| 2021-02-15 16:41 | geoffclare | Resolution | Open => Accepted As Marked |
| 2021-02-15 16:41 | geoffclare | Tag Attached: tc3-2008 | |
| 2021-03-08 15:21 | geoffclare | Status | Resolved => Applied |
| 2024-06-11 09:08 | agadmin | Status | Applied => Closed |
