Re: [Exim] Bcc (again)

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Drav Sloan
Fecha:  
A: Philip Hazel
Cc: Exim Users Mailing List
Asunto: Re: [Exim] Bcc (again)
Philip Hazel wrote:
> 2a. I argue that the choice can be made only in the MUA. If an MTA has
>     to do anything, all it can do is remove Bcc: completely; it can't
>     offer the sender a choice.


I agree on that philosophy. An MTA is not expected (as far as I'm concerned)
to honour Bcc's (i.e act on them and attempt the bcc delivery). The downside
is that there are multiple ways to inject mail (as you point out below), and
I don't think it's an easy yes/no.

> If it is the case that all users expect Bcc: never to be sent out, and
> the option of including it for some (bcc) recipients is in practice
> something that is never used or wanted, then Exim could of course be
> made to remove it (possibly optionally) to catch cases where the MUA
> doesn't.


I don't see why this is a problem. I think most MTA's will drop Bcc's
(I know sendmail and qmail weed them out (at certain places)).

> Questions:  1. Should Exim always remove Bcc: header lines:
>                (a) On messages received locally, not via SMTP?


yes. (I assume you mean a exim -bs or an exim -t?)

>                (b) On messages received using local SMTP on stdin/stdout?


yes. Infact this maybe a place to honor bcc (i.e process it).

>                (c) On messages received using SMTP over the loopback
>                    interface?


yes - but I'd expect people to want this to be optional

>                (d) On messages received from other hosts? Note that this
>                    includes "local" mail from MUAs on workstations, etc.


no. By this point a MTA shouldn't _really_ edit the mail, save things an
admin chooses to add. Again this could be optional. You could be clever and
drop it if it doesn't match the env-to. But personally I try to do little
to headers on externally recieved emails (unless it is something under
my control).

>             2. If the answer to any of 1 is yes, should this be
>                optional?


It would be nice to have it optional, that way people who _do_ want
to keep those headers can. I personally believe that stripping bcc's
is the correct thing to do if the env-to's don't match the bcc
(the only case I'd actually expect a bcc to be there is when it's for
the intended recipient).

>             3. What does Sendmail do? (The book doesn't seem to say.)


Strips it in all instances as far as I can see (tried via command line
remote smtp, localhost smtp and matching env-to's/bcc's).

>             4. What do other MTAs do? I will collect and publish a
>                summary of any information collected.


Qmail strips headers from anything sent locally via /usr/lib/sendmail
(usually linked to qmail-inject), though it retains bcc headers
passed via port 25 (localhost and remote).

Just to recap I personally like the idea of being able to strip them,
remote smtp should be untouched, exim -t injections would be nice if
honored - i.e attempted to be delivered (configurable).

Regards,

D.

-- 
    David Sloan - Senior Mail and News Systems Admin - Platform Management
  Tel: +44 845 272 0666    Fax: +44 20 8371 1167    Email: dsloan@???