I was seeing some strange behaviour with 'control=submission' rewriting the
envelope sender of messages, and I was carefully reading and re-reading the
documentation... until I found that in NewStuff this had been intentionally
changed.
I don't think I like the new behaviour, and I'd like it to be back how it
was before (or have an option to do this). That is:
- leave the envelope sender untouched
- remove any existing Sender: header
- add a new Sender: header based on the $authenticated_id
With the new behaviour, to leave the envelope sender alone I must set
/sender_retain, but then I lose the Sender: header processing.
To explain why I think this is a reasonable thing to want to do, let me
describe the situation:
+----------------+ +---------+
| untrusted |------------->| relay |-----> outside world
| box | | |
+----------------+ +---------+
(running CGIs) (implements rate
limiting etc)
On the untrusted box, CGIs can submit mail to the relay by either:
(1) opening an SMTP connection to the relay, or
(2) invoking /usr/sbin/sendmail which is really exim in mua_wrapper mode
which submits it for them
Packet filtering prevents CGIs opening connections on port 25 to anywhere
other than the relay box.
In both cases the relay knows the real ID of the sender: in case (1) it uses
identd information, and for case (2) it uses SMTP AUTH with the EXTERNAL
mechanism as described by Tony Finch in his excellent paper at
http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/talks/2005-02-eximconf/paper.html
(because exim is running setuid to the 'exim' user, the ident information
just says 'exim')
So, we have an authenticated ID for the connection like 'web12345', and this
is used as the key into the rate limiting code in exim-4.52 (which is
wonderful, incidentally)
The relay box does call-forward verification, so that it has a fairly high
confidence that mail can be delivered before accepting the message for
relaying. However, bounces could still be generated:
(a) if the final recipient rejects mail at the DATA phase or later
(b) if there was a temporary error during recipient verification (I have
"defer_ok" set), the message is accepted and queued, but the final delivery
fails.
Now, on the untrusted box I think it's perfectly reasonable for users to set
their own envelope senders. Each CGI script might want bounces to go to a
different place; and forging envelope senders doesn't gain them anything
(the rate limiting prevents them from sending spam, and it doesn't need to
trust the envelope sender to limit each user separately).
However, in the case where CGIs open a direct SMTP connection to the relay
box I would like to fixup the message using submission mode, and I would
*like* it to fix up the Sender: header appropriately as it gives a good clue
where the message came from in the event that one of the CGIs was being
abused. OTOH I don't want the envelope to be rewritten as
<web12345@???> as that is not a valid return address, and any
system which does callback verification will reject the message, and I don't
want to have to maintain a table which maps each site to its "allowed"
envelope sender.
I think I would like /sender_retain to go back as it was, and a new option
/fixup_return_path (or something) to overwrite the return path with the
validated Sender in submission mode.
Am I being unreasonable? :-)
Regards,
Brian.
