In article <Pine.SOL.4.44.0205160948360.12096-100000@???>,
Philip Hazel <ph10@???> wrote:
>On Wed, 15 May 2002, Miquel van Smoorenburg wrote:
>> I wanted to use the $recipients expansion variable, but it is
>> forbidden outside of the system filter "to prevent exposure of Bcc
>> recipients to ordinary users".
>>
>> But wouldn't it be a good idea to lift this restriction when
>> a transport is run ?
>
>But $recipients contains *all* the recipients for a message, not just
>those recipients that apply to a single run of the transport. And it
>contains the envelope-to addresses.
I see. That won't work, then.
>> I'm assuming here that $recipients at local-transport-time is
>> just the list of addresses passed to that transport, right ?
>
>$recipients at transport time doesn't exist. So you can't make any
>assumptions about it! :-)
Yes, I enabled it in the source, and got a nice SIGSEGV, which
made me come to the same conclusion.
>You can get what you want by storing the message in BSMTP format, but
>maybe that isn't suitable for you. However, I wouldn't recomment using
>"Envelope-To" for data that isn't envelope data. That's confusing.
Well, there's a difference between "incoming" envelope-to and
"outgoing" envelope-to. For example, if I use the following aliases:
anakin@???: anakin@???
*@potter.book: /var/mail/potter/
(this would be not an alias but a router
that delivers there, but I'll keep it simple)
.. and I mail to anakin@???, then in /var/mail/potter, the
current (incoming) envelope-to would be "Envelope-to: anakin@???"
while the outgoing envelope-to such as bsmtp uses it would be
"RCPT TO: anakin@???".
So you're absolutely right when you say I can get what I want
by using BSMTP format, the thing is that in my current application
I want to enable both POP3 and SMTP access to the same mailbox.
I have already written a daemon that allows ATRN (RFC2645) access
to maildir type mailboxes. This is pretty hard to do with a bsmtp
spool file - I want one file per message and compatibility with
existing POP3/IMAP servers and even MUAs. That means maildir
with Envelope-to: and Return-Path headers.
If I'm starting to bore you now, feel free to ignore the rest of
this message - I'll try to explain a bit more what I'm trying to do,
and you might say exim was not meant for that or that I am abusing
the system. So be it ;)
It's certainly true that I probably need to think this over some
more, but one way of doing that is by composing this message.
If I want to put all mail for the domain "potter.book" in one
maildir mailbox, with envelope-to so I can send it on using SMTP,
then I can set up aliases like this:
*@potter.book: harry
.. and everything is nicely put in the 'harry' mailbox.
However when I create another alias (or someone uses a .forward) like
anakin@???: anakin@???
.. then the Envelope-to: is "anakin@???". Obviously, the
SMTP server that the contents of "harry" is going to be dumped
to is only going to reckognize addresses in the "potter.book"
domain and will refuse "anakin@???".
Now I could use the "outgoing envelope" as discussed above, if
I added that to exim, but in this case it would be "harry" for all
recipients.
So that doesn't work. Another solution is to keep aliases for
entire domains and aliases for users in domains apart, and dump
everything for "potter.book" directly into /var/mail/harry/
Then, the "outgoing envelope-to" would be correct, even in the
case of aliasing. It would be hard to treat this as a normal
mailbox with normal properties, but with some extra routers,
an added getpwnam lookup method, and using address_data, it
would be possible.
Another solution is a patch that can mark an alias in a forwardlist
as "envelope-to" address. I already did the work for exim3, and I
just ported it to exim4. Basically it sets a flag on the address
which makes write_env_to() stop going up the tree for parent
adresses when writing envelope-to information.
That looks like this:
*@potter.book: harry
anakin@???: >anakin@???
The ">" in this case means something like "forward to instead of alias".
The only thing that it does is that it makes *that* address the
envelope-to instead of any parents (earlier aliases or original address).
The effect of mailing to "joe@???,anakin@???" for the
envelope-to header is:
Envelope-to: joe@???,
anakin@???
It is the easiest solution, just a few-line patch, but probably the
hardest to document...
>One possibility is to make use of headers_add on your aliasing routers
>(which will be easier in Exim 4 than in Exim 3), though it might mean
>you end up with multiple copies of the added header.
Doesn't work, alas. If you mail to several people in the same domain,
only the first one is added in the header if you set
headers_add = "X-Envelope-To: $local_part@$domain\n"
Mike.
--
"Insanity -- a perfectly rational adjustment to an insane world."
- R.D. Lang
