Hello? (was Re: Adding Envelope Headers?)

[John Rudd]

Julian,

Unless the MTA uses and removes the Envelope-To headers.  In that case,
your "ruins the point of BCC" argument is completely wrong.

(I get the feeling you didn't read the original message I wrote in this
thread)

Think of it like this: combine the sendmail qf file and df file into
one file.  What you're essentially saying is that "you shouldn't put
RPFD lines into the qf file, because the user might see them".  No,
sendmail uses those lines, and removes them, before putting the qf data
(headers, etc.) into the final message.  Your worry is unwarranted.

Some MTAs, such as CommuniGate Pro, put it all into one queue file.  If
the file format is (and it is important that all of the Envelope-To's
precede any other headers):

(one or more Envelope-To: lines)
(one Return-Path: line, which is the Envelope From)
(rest of RFC-822 message)

then that file can be directly submitted to CommuniGate Pro's
"Submitted" directory (if the file's name is *.sub), and it will do the
right thing.  It will read the Envelope-To's and use them for the
recipients, remove them from the message, and then use the Return-Path
as the Envelope From (keeping it in the message).

If MailScanner would accept and generate that format as a "plain" or
"CGP" MTA setting, then it could be used for scanning RFC-822 messages
and for supporting CommuniGate Pro.  (the relay could be taken from the
first Received line)  Then you'd just tell MailScanner to name its
result something.sub, use (non-batch mode) to put the files into the
regular queue directory (which you'd set to be CGP's "Submitted"
directory).

Users will NOT see the "Envelope-To" headers.  Your argument does not
hold.  Some MTA's will "do the right thing" with it.


(as a side note)
The CGP queue file is in a slightly different format, but it will
accept the above format for the "Submitted" directory.  The actual CGP
queue file format is:

(multiple queue info lines)
(blank line)
(RFC-822 message)

the queue info is lines of the following format:
P ? (date) (time) (number) (flags1) (flags2) <sender>
R ? (date) (time) (number) (flags1) (flags2) <recipient>
S (STMP|PIPE|etc) [W.X.Y.Z]   # module that received mesg, and the relay
O L                           # I'm not actually sure what the OL line
is

(the only parts that are important to MailScanner are the last fields
of the P, R, and S lines, the rest can pretty much be thrown out ... I
do that with my cgp2ms perl script, though I don't use the S line, I
use the first Received header ... and I use it to fake a sendmail qf/df
file pair; the ms2cgp perl script (which is used for MailScanner's
"Sendmail2" variable) takes the sendmail qf/df pair and creates an
Envelope-To formatted file, and puts that into the CGP submitted
directory ... so far, no one has mentioned seeing the Envelope-To
lines, by the way)

This could be munged by another process into the Envelope-To format, so
that MS only has to support 1 format for both reading and sending ...
or it could read the queue format and generate the Envelope-To format.
Either way.  (or, a "plain" MTA might read and write Envelope-To
format, while a "CGP" MTA might read the CGP queue format and write the
Envelope-To format ... that would probably be ideal)

Anyways, the point is, Envelope-To is not the problem you think it is.
It's actually very useful, once you realize that some MTA's will "do
the right thing" with it.



On Feb 20, 2004, at 12:29 AM, Julian Field wrote:

> If you send a message to someone on the same mail server as you, and
> you
> Bcc another person on the same mail server, then both recipients would
> appear in the "Envelope-To" header, revealing to the first person that
> the
> message was also sent to the second person. Which rather ruins the
> point of
> being able to Bcc in the first place.
>
> At 23:12 19/02/2004, you wrote:
>> Julian,
>>
>> The message isn't answerable by anyone but you -- it's a reply to your
>> message about how putting "Envelope-To" headers into a message would
>> be
>> a bad idea (my response says that it's bad in the general cause, but
>> not
>> in some specific cases, which would be based upon the MTA, and should
>> therefore be selectable by the sysadmin running mailscanner).
>>
>> a) doesn't apply because I'm not reporting a problem, I'm refuting an
>> assertion of yours,
>>
>> and
>>
>> b) doesn't apply because you're the only one being addressed, really.
>> That "other's can't answer because they don't know" isn't relevant.
>>
>>
>> John
>>
>>
>> Julian Field wrote:
>> >
>> > Sorry, haven't got time to respond to everyone. I suggest the
>> silence means
>> > no-one else either
>> > a) has enough info from you to work out what the problem is,
>> > or
>> > b) doesn't know.
>> >
>> > At 21:41 18/02/2004, you wrote:
>> > >John Rudd wrote:
>> > > >
>> > > > John Rudd wrote:
>> > > > >
>> > > > > Julian Field wrote:
>> > > > > >
>> > > > > > At 14:00 13/02/2004, you wrote:
>> > > > >
>> > > > > > >X-Envelope-To:
>> > > > >
>> > > > > > I am of the opinion that ...
>> > > > > > putting in the envelope recipient is a bad idea.
>> > > > >
>> > > > [snip]
>> > > > > When you know that the MTA will do the right thing, it's not
>> "a bad
>> > > > > idea".  And for some MTA's, it's definitely "the right idea".
>> > > >
>> > > > So, does the lack of response to my two messages indicate they
>> fell on
>> > > > deaf ears?  Are my arguments unconvincing?
>> > >
>> > >
>> > >
>> > >*tap*tap*tap* Is this thing on?
>> > >
>> > >Beuller?  Beuller?
>
> --
> Julian Field
> www.MailScanner.info
> MailScanner thanks transtec Computers for their support
>
> PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654