Mailing List Archive

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=248


holmgren@lysator.liu.se changed:

What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|ph10@hermes.cam.ac.uk |holmgren@lysator.liu.se
Status|NEW |ASSIGNED




------- Comment #3 from holmgren@lysator.liu.se 2007-01-25 19:14 -------
Created an attachment (id=53)
--> (http://www.exim.org/bugzilla/attachment.cgi?id=53&action=view)
Preliminary solution adding new variables, setting those in smtp_connect(), and
deferring helo_data expansion

Can the getsockname(2) call be made in smtp_connect() (so that it can be reused
for both delivery and verification)? The variables should be reset when closing
the connection. To maintain abstraction, we then need a new smtp_close()
function that does that and is called in place of close(2).

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=248





------- Comment #4 from holmgren@lysator.liu.se 2007-01-26 02:46 -------
I've been thinking ... are there any other options, besides helo_data, that can
make use of these new variables? And is there any other setting that makes
sense except "${lookup dnsdb
{ptr=$sending_ip_address}{$value}{$primary_hostname}}" or "${lookup dnsdb
{ptr=$sending_ip_address}{$value}{[$sending_ip_address]}}"?

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=248


ph10@hermes.cam.ac.uk changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED




------- Comment #5 from ph10@hermes.cam.ac.uk 2007-01-30 15:16 -------
(In reply to comment #3)
> Preliminary solution adding new variables, setting those in smtp_connect(), and
> deferring helo_data expansion

I have committed this patch - modified to fix two bugs (just to prove I do read
patches before applying them. :-) (1) By moving the code in verify.c, you lost
the values of $domain during the expansion of helo_data. (2) More importantly,
by putting the expansion after connect() in smtp.c, you lost the value of
helo_data completely when delivering a second message down the same SMTP
connection, and this caused a problem when TLS was in use, when another EHLO
takes place. The tests run OK with my fixes, and I've added a few more tests
too.

> The variables should be reset when closing
> the connection. To maintain abstraction, we then need a new smtp_close()
> function that does that and is called in place of close(2).

I haven't done this; typically after close() Exim will either end the process,
or make another connection, so I wasn't sure that it was worth it.


--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=248





------- Comment #6 from holmgren@lysator.liu.se 2007-01-30 16:21 -------
On Tuesday 30 January 2007 16:16, ph10@hermes.cam.ac.uk wrote:
> I have committed this patch - modified to fix two bugs (just to prove I do
> read patches before applying them. :-) (1) By moving the code in verify.c,
> you lost the values of $domain during the expansion of helo_data.

Ah, didn't see that.

> (2) More
> importantly, by putting the expansion after connect() in smtp.c, you lost
> the value of helo_data completely when delivering a second message down the
> same SMTP connection, and this caused a problem when TLS was in use, when
> another EHLO takes place. The tests run OK with my fixes, and I've added a
> few more tests too.

I suspected that passed-on connections could pose problems, but then I thought
that TLS would always be started by the same process that sent the first
EHLO, and that no further EHLOs were needed. I can see that it is possible to
send a message without TLS first, then pass on the connection to the next
delivery process, which issues STARTTLS and the new EHLO, but under what
circumstances would that happen?

> > The variables should be reset when closing
> > the connection. To maintain abstraction, we then need a new smtp_close()
> > function that does that and is called in place of close(2).
>
> I haven't done this; typically after close() Exim will either end the
> process, or make another connection, so I wasn't sure that it was worth it.

I was mostly concerned about callout verifications, after which
$sender_ip_address and $sender_port will still be set.

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=248





------- Comment #7 from ph10@hermes.cam.ac.uk 2007-01-30 16:39 -------
(In reply to comment #6)
> I suspected that passed-on connections could pose problems, but then I thought
> that TLS would always be started by the same process that sent the first
> EHLO, and that no further EHLOs were needed. I can see that it is possible to
> send a message without TLS first, then pass on the connection to the next
> delivery process, which issues STARTTLS and the new EHLO, but under what
> circumstances would that happen?

Always! The first process has to shut down TLS before it passes the connection
to a new process. The new process then starts it up again. That's the only way
I could make it work, since the TLS processing data is held in the process and
cannot be passed on.

> I was mostly concerned about callout verifications, after which
> $sender_ip_address and $sender_port will still be set.

The easiest would then be to reset in that particular case. Or we could
document it as a feature. (Only joking).

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##