headers
Philip Hazel | 6 Aug 2004 12:04
Picon
Picon

Re: Exim's handling of Bcc lines (was Re: [BUG] mutt 1.2.5 sends mail with Bcc: header)

On Mon, 26 Jul 2004, Phil Pennock wrote:

> Having software second-guess intentions is a recipe for trouble.  The
> software which can best determine intent/necessity should do so.  If the
> MUA knows that somebody is not supposed to see a line, the MUA is in the
> best place to enforce it.

For the record, I happen to have noticed this comment, which was sent by
Keith Moore to the ietf-822 mailing list. Keith has been involved in the
development of email standards for many years. He wrote:

OP:   > No, MUAs often send raw message text to an executable transport agent
OP:   > (e.g. sendmail) which examines the message header to determine
OP:   > recipients.

KM:   in that case, sendmail is performing part of the MUA's function.
KM:   nothing says that the entire MUA has to be implemented in a single
KM:   program.

In other words, he supports my statement that when Exim is constructing
the envelope from the header lines (the -t option), it is performing an
MUA function, a point that Derek was disputing earlier.

(I'm only just back. It will be some time before I get round to writing
a document to get this issue more widely discussed.)

Regards,
Philip

--

--
(Continue reading)

Permalink | Reply | 4 comments |
headers
Edgar Lovecraft | 8 Aug 2004 07:37
Picon

Re: Exim's handling of Bcc lines (was Re: [BUG] mutt

Just as a side note to all of this, I did some testing when this thread
first come up and sent the results on to Derek, perhaps he can dig up that
email and post it here...

I injected a 'raw' message into various MTA's ran by various companies
that I have accounts with or 'relay access' to, by using a standard
command prompt telnet session.  The message I injected contained
a BCC header with multiple addresses in them, and to my thinking, this is
a sendmail does one thing, everyone else (or nearly everyone) does another
problem.

The two sendmail and one Lotus Notes 5 server either removed or striped
the BCC header, while Exim, OpenWave InterMail, MS SMTP, MS Exchange, and
qmail (I did not test postfix that I remember) all left the BCC header
intact and unmodified.

My personal opinion on this goes along these lines....
Sendmail has historically been a part of the MUA (or rather, part of the
MUA) for many *nix mailers and utilities, and therefore has been
defaulted (don't know if you can change this behavior, but searches on
Google news groups seems to say no) to strip the BCC header for the
client regardless of how the message is accepted, or from where it comes.
Since the other SMTP software have been primarily for the MTA parts of the
transactions only, they do as an MTA should, and leave the message headers
and body intact without modification.

So, outside of the Sendmail world (with a few exceptions, Lotus being one)
it seems that all other MTA software expects the MUA to decide what and
how the BCC header is to be handled.  MS Outlook/Outlook Express for 
example never send a BCC line ever, I do not know, nor have I tested
(Continue reading)

Permalink | Reply | 3 comments |
headers
Nico Erfurth | 8 Aug 2004 11:46
Picon

Re: Exim's handling of Bcc lines (was Re: [BUG] mutt

Edgar Lovecraft wrote:

> The two sendmail and one Lotus Notes 5 server either removed or striped
> the BCC header, while Exim, OpenWave InterMail, MS SMTP, MS Exchange, and
> qmail (I did not test postfix that I remember) all left the BCC header
> intact and unmodified.

Postfix also removes it. But when I understood the source, that's more 
by accident, because the cleanup daemon does not know where the mail 
originates from.

Nico
Permalink | Reply | 2 comments |
headers
Philip Hazel | 13 Aug 2004 12:20
Picon
Picon

Re: Exim's handling of Bcc lines (was Re: [BUG] mutt

The Bcc Issue: posted to the exim-users, exim-dev, and ietf-822 mailing lists
-----------------------------------------------------------------------------

The issue of who handles Bcc: header lines has again been raised, and I
am seeking opinions as widely as I can. The requirement is
straightforward: non-Bcc recipients of a message should not see the
addresses of any Bcc recipients, that is, their copies of the message
should not contain Bcc: header lines.

The dispute is over who achieves this end by removing Bcc: lines when
they should not be present. Is it the MUA or the MTA? This is what I
know about current behaviour:

1. Exim (which I maintain) removes Bcc: lines if, and only if, it is
    called with the -t option. In that case, it is constructing an
    envelope from the header data, and IMHO in doing so it is fulfilling
    an MUA function. In all other cases it leaves Bcc: lines alone.

2. It has been reported to me that OpenWave InterMail, MS SMTP, MS
    Exchange, and qmail behave in the same way as Exim for incoming SMTP
    messages (i.e. they leave Bcc: lines alone).

3. I have also been told that Sendmail, at least in some configurations,
    always removes any Bcc: lines from any message that it handles. The
    same is apparently true of Postfix and Lotus Notes 5.

4. Among the MUAs, I think that Pine never sends Bcc: lines, but Mutt by
    default does, assuming that the MTA will deal with them (Mutt does
    not use the -t option).
(Continue reading)

Permalink | Reply | 1 comment |
headers
Philip Hazel | 18 Aug 2004 12:38
Picon
Picon

Re: Exim's handling of Bcc lines (was Re: [BUG] mutt

Summary of the Bcc discussion: posted to exim-users, exim-dev, & ietf-822

There were a few responses on the exim-users mailing list. There was a
longer discussion on the ietf-822 mailing list, to which a number of
people who have worked in email protocol development for many years
contributed. These included Keith Moore (author of several RFCs), Dave 
Crocker (author of RFC 822), and Tony Hansen (another RFC author).

Some more data points were posted: Smail-3 behaves like Exim; Elm and 
Mulberry behave like Pine (they do their own Bcc: processing).

1. The substantive point

With one possible exception, everybody's opinion was that an MTA has no
business messing with Bcc: header lines. Here is a quote from Tony
Hansen:

   "The MUA, however it is constituted, should handle all BCC processing,
   and the cloning of messages with and without the Bcc: header."

This confirms my belief that Exim's default behaviour is the correct 
one. I hope this particular issue is now laid to rest once and for all.
I have saved all the responses just in case it arises again in the 
future.

The possible exception was a post containing this paragraph:

   The /usr/[s]bin/sendmail interface is a proprietary interface
   introduced by Sendmail. So all other applications providing this
   interface should be as close to Sendmail's behaviour as possible, i.e.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nigel Metheringham | 20 Aug 2004 11:23
Picon

Administrivia - Exim list migration to new machine

The sharp eyed among you may have noticed that over the last 24 hours
things have been rearranged so that mail to exim.org and the website is
going to the Cambridge University open projects development machine -
sesame.csx.cam.ac.uk.   This should have had minimal effect on
functionality (although its been good for me since we are now dropping
virus messages and spam before they hit the mail moderation interface).

The next stage is to migrate the lists themselves across.  This will
happen over the weekend.   I will as far as I can keep people's settings
(nomail, digest etc) intact, however the passwords will all be reset to
default ones generated by mailman.  I will force a password reminder
message when the changeover has been completed.

Following the changeover, all exim list mail will use VERP  This means
the sender address will look something like
  exim-user-bounces+nigel.metheringham=dev.intechnology.co.uk <at> exim.org

Those filtering on sender address will need to change their filters
appropriately.

The mailing list archives for exim-users will be taken across as is,
with no change to the URLs.  New archives for the list will be under a
different URL.  The other lists will be converted to the new archive
URLs [The intention is to keep old useful URLs stable, but the size of
the old archives is so large that they are hard to index and too
imposing to work through so a new start is useful].  I will add
searching pretty soon - the archives are set up for it.

Other things may flap a little during the changeover - I think rsync is
currently broken, but will attempt to fix it shortly.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Nigel Metheringham | 21 Aug 2004 10:54
Picon
Gravatar

Test message to clear moderation queue - discard


--
Permalink | Reply | 0 comments |
headers
Michael Kefeder | 23 Aug 2004 22:55

possible bug: sieve filter not working when router uses data instead of file

Hi List,

I started to play a little bit with Exim 4.41 and filters. I use a setup 
where account data is stored in a mysql database, and i wanted to store 
the filters there too. Thats why i used the following router and 
transport to enable filters per user:

# ROUTER
xams_forward:
   driver = redirect
   address_data = ${lookup SQL_QUOTA_SITENAME}
   allow_filter
   check_ancestor
   user = mail
   directory_transport = xams_address_file
   no_expn
   data = ${lookup SQL_FORWARD_DATA{${value}}}
   domains = +xams_domains
   file_transport = xams_address_file
   pipe_transport = address_pipe
   reply_transport = address_reply
   retry_use_local_part
   no_verify
   router_home_directory = /var/mail/${lookup 
SQL_GET_SITENAME{${value}}}/${lc:$local_part}
   transport_home_directory = 
/var/mail/${extract{sitename}{$address_data}}/${lc:$local_part}

# TRANSPORT
xams_address_file:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nigel Metheringham | 24 Aug 2004 10:18
Picon

Re: possible bug: sieve filter not working when router uses data instead of file

On Mon, 2004-08-23 at 21:55, Michael Kefeder wrote:
> p.s.: I hope posting to exim-dev is ok for this mail, because i think it 
> is a bug i'm describing here.

Please could you repost to exim-users - exim-dev is actually about the
development process as we transition from a single developer structure
(with contributions) to a collaborative development structure.  It may
become a developers list later but thats not its current target.

I'm currently writing up stuff on the list structures, I'll push it out
as soon as I can.

	Nigel.
--

-- 
[ Nigel Metheringham           Nigel.Metheringham <at> InTechnology.co.uk ]
[ - Comments in this message are my own and not ITO opinion/policy - ]

--
Permalink | Reply | 0 comments |

Gmane