On Sunday, January 19, 2014 12:12:08 Chris Knadle wrote:
> On Sunday, January 19, 2014 11:04:52 Jasen Betts wrote:
> > On 2014-01-19, Chris Knadle <Chris.Knadle@???> wrote:
> > >> A better approach is to set it statically but duplicate the transport,
> > >> have one for each interface and then, in the router, use a conditon
> > >> or use an expansion for the transport name.
> > >
> > > Yes I like this, thanks for pointing it out. :-)
> >
> > It's not perfect though, the retry records get shared between both
> > outbound addresses, this can be bad. If someone (recipient MX) blocks
> > one address (eg: using a firewall), the other can refuse to try.
> > There's a work-around that involves just using an expansion in
> > one of the parameters. I forget which. (I think, ironically, that it
> > may be the interface parameter)
>
> Hmm. I'm not quite sure I understand this; it sounds like retry records
> thus differ depending on which router or transport they went through.
> However I'm not in a rush to try to merge the configuration, although I
> seem to have another issue which may make me want to try to.
>
> Messages received from the second Exim listening on eth0:0 appears
> (though this doesn't make sense) to be sending mail to "itself" on the
> primary interface that it's not actually listening on. The two daemons
> have separate logging areas, and the logs for the "normal" Exim daemon
> listening on the primary interface does not show mail passing through it.
> But the headers on received messages show a second Received: line of the
> mail passing to the primary interface.
>
> Legend:
> ["primary" interface eth0: 64.85.165.57 ("lethe"), eth0:0: 64.85.165.58
> ("lethe2")]
>
> Received: from lethe2.ofobscurity.com ([64.85.165.58]
> ident=e0cc407ce62008148c73709d627ca082) by lethe.ofobscurity.com with esmtp
> (Exim 4.80)
> (envelope-from
> <coredump+bounces-33-chris.knadle=coredump.us@???>) id
> 1W4ZKV-0000R0-1x
> for chris.knadle@???; Sat, 18 Jan 2014 12:05:07 -0500
> Received: from lethe.ofobscurity.com ([64.85.165.57]
> ident=d11ec0054d91a340b8193f0da08e4130) by lethe2.ofobscurity.com with smtp
> (Exim 4.80)
> (envelope-from
> <coredump+bounces-33-chris.knadle=coredump.us@???>) id
> 1W4ZKV-0000Qv-4L
> for chris.knadle@???; Sat, 18 Jan 2014 12:05:07 -0500
> Received: from pool-173-77-210-97.nycmny.fios.verizon.net ([173.77.210.97]
> helo=trelane.coredump.us) by lethe2.ofobscurity.com with esmtps
> (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80)
> (envelope-from <Chris.Knadle@???>)
> id 1W4ZKP-0000QZ-3s
> for coredump@???; Sat, 18 Jan 2014 12:05:07 -0500
>
> This second Received: line in the headers is a problem, because it means if
> one IP gets flagged in an RBL , then they likely both will. The third
> Received: (at the top) is fine -- that's the mail passing from one daemon to
> another to send the message to my private mail, and that transfer is in the
> logs for both daemons.
>
> Another curious hint is that if I don't allow mail relaying from the primary
> interface, then mail going to the (test) mailing list address on eth0:0
> gets rejected, "relay not permitted", even though I have the domain used
> for the list set in relay_to_domains. I've likely got a fundamental
> misconfiguration, though what it is isn't immediately obvious to me.
So as it turns out this wasn't a misconfiguration; the reason the log looks
this way is due to the way mlmmj works. mlmmj submits mail via SMTP, and it
gets the HELO to use via a gethostname() call (which on Linux gets the
hostname via a uname() call), then a gethostbyname() call to get the FQDN to
use. Neither the outbound HELO to for SMTP nor the source IP address to use
seem to be settable at present. Seems like the right thing to do here is to
patch mlmmj to add these facilities.
Without doing that, I've found two ways so far of handling the "wrong"
Received: header in Exim: either set header_received_text conditionally (this
works well but feels wrong), or to use "headers_remove = Received" in one of
the routers. So far the latter isn't able to remove only the middle Received:
header for the lethe -> lethe2 step; it can either remove the initial
Received: header as the mail comes in (in the mlmmj_router), or all of them as
the mail goes out (in the dnslookup_relay_to_domains router), leaving the only
Received: header being added by the destination MTA. Neither of those seem
right. So for now I'm setting header_received_text.
Possible minor documentation bug: the received_header_text (chapter 14) uses
"tls_in_cipher" which at least for exim 4.80 is a nonexistent variable; I used
tls_cipher in its place.
-- Chris
--
Chris Knadle
Chris.Knadle@???
