Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001408 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Enhancement Request 2020-09-30 20:48 2021-03-08 15:21
Reporter steffen View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Applied  
Name steffen
Organization
User Reference
Section Vol. 3: Shell and Utilities, mailx
Page Number 2952
Line Number 97836
Interp Status ---
Final Accepted Text Note: 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
Attached Files

- Relationships

-  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.



- Issue History
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 => Note: 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


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker