Auteur: Jasen Betts Date: À: exim-users Sujet: Re: [exim] Exim authentication as client and $sender_address
On 2013-06-01, Sebastian Arcus <shop@???> wrote:
>>> 1. Does Exim authenticate as a client and send one message at a time by
>>> default (and authenticate again for next message to be sent) - or does
>>> it try to send several messages on the same authentication session?
>>
>> By default the smtp transport will send as many emails as possible,
>> you can set connection_max_messages to 1 to limit this to a single
>> email per connection, or you can create several tranports one for each
>> user.
>>
>>> 2. If it tries to send several messages in one go after authenticating -
>>> what does $sender_address refer to? Is it the sender address of the
>>> first message which it tries to send?
>>
>> It's empty unless they all have the same sender. (same deal with all
>> other variables in the smtp transport)
I'm wrong here that pruning of the variables is done for each
recipient, (not for each email) the transport only sees one message at
a time. when it completes the TCP connection is recycled and passed to
a new exim process to transport the second message.
RFC4954 only allows (successful) AUTH once per SMTP connection so any
subsequent emails are going out under same authority as the the first
email.
many (most?) smtp providers allow authenticated session to use any
envelope or email header sender.
> Thank you for the info Jasen. I've been using $sender_address in client
> authenticator for smtp smart relay for 3-4 years now. I don't use
> $connection_max_messages (yet).
The troubles I've had with subsequent messages going through the wrong
transport unrelated to your usage
> Thank you for the info Jasen. I've been using $sender_address in client
> authenticator for smtp smart relay for 3-4 years now. I don't use
> $connection_max_messages (yet). These are sites with up to 10
> workstations connecting to the internal smtp server (which in turn
> relays to the provider's smtp server). I haven't had any problems with
> this so far - as far as I know. Would this mean that I was just lucky,
> and exim happened to be sending just one message at a time out of sheer
> luck?
what will mostly happen is that exim is doing immediate deliveries so
the delivery process is spawned immediately for each message submitted
if your internet conection, and smarthost provider are reliable this
will always succeed. if they wind up on the queue instead they'll be
delivered after the next email going to that smarthost.
If you provider supports STARTTLS but only allows it to be used once
per session exim will not attempt to send a second email out that
connection, and so will re-connect (and thus authenticate) before
each email. (this is acknowledged as a (minor) bug in exim and may
at some future time be fixed (which may will hurt your usage))
Most of the details can be found by reading chapter 3 of the spec
(repeatedly if neccessary)