Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

How to disable TLS in exim4 client part?

1,847 views
Skip to first unread message

Alois Mahdal

unread,
Jan 1, 2012, 7:20:02 PM1/1/12
to
Hello!

Please, how do I disable TLS in exim4 as a client?

I'm trying to send all emails via single SMTP smarthost,
but for some reason, server does not deliver them, so I
want to look into the trace. But exim4 keeps negotiating
TLS, not making life easier for me--the Mallory. (Not that
it should... :))

I tried adding MAIN_TLS_ENABLE = no to exim4.conf.template
(AND to conf.d/main/03_exim4-config_tlsoptions), but this
does not affect client.

So what should I do?

TIA,
aL.

--
Alois Mahdal, using Opera's revolutionary e-mail client:
http://www.opera.com/mail/


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/op.v7fiz...@aloism.cz.avg.com

Joe

unread,
Jan 2, 2012, 4:00:02 AM1/2/12
to
On Mon, 02 Jan 2012 00:46:44 +0100
"Alois Mahdal" <Alois.Mahd...@zxcvb.cz> wrote:

> Hello!
>
> Please, how do I disable TLS in exim4 as a client?
>
> I'm trying to send all emails via single SMTP smarthost,
> but for some reason, server does not deliver them, so I
> want to look into the trace. But exim4 keeps negotiating
> TLS, not making life easier for me--the Mallory. (Not that
> it should... :))
>
> I tried adding MAIN_TLS_ENABLE = no to exim4.conf.template
> (AND to conf.d/main/03_exim4-config_tlsoptions), but this
> does not affect client.
>
> So what should I do?
>

Is there anything useful in /var/log/exim4/mainlog? That at least
should be in plaintext.

Joe


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120102085...@jretrading.com

Alois Mahdal

unread,
Jan 3, 2012, 12:40:02 PM1/3/12
to
Sorry for delay.

On Mon, 02 Jan 2012 09:51:14 +0100, Joe <j...@jretrading.com> wrote:
> Is there anything useful in /var/log/exim4/mainlog? That at least
> should be in plaintext.


Lines in Exim4 sound like purring to me:

-----8<-----
2012-01-02 14:09:46 1Rhhe6-00059F-9d <= alo...@gebba.aloism.test.local
U=aloism P=local S=442
2012-01-02 14:09:46 1Rhhe6-00059F-9d => correct....@mydomain.cz
<Correct....@mydomain.cz> R=smarthost T=remote_smtp_smarthost
H=local.gate.cz [10.1.2.3] X=TLS1.0:RSA_AES_256_CBC_SHA1:32
DN="C=CZ,ST=Czech Republic,L=Town,O=Company,CN=cn.local.gate.cz"
2012-01-02 14:09:46 1Rhhe6-00059F-9d Completed
----->8-----

I have obuscated many fields, the adresses there are correct (I also tried
the e-mail address in lowercase), except for one thing I'm not sure about:
this part, which is literally:

"R=smarthost T=remote_smtp_smarthost"

I could not find in Exim4 specs what these fields should be.

TIA,
aL.

--
Alois Mahdal, using Opera's revolutionary e-mail client:
http://www.opera.com/mail/


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/op.v7iqz...@aloism.cz.avg.com

Joe

unread,
Jan 3, 2012, 1:20:02 PM1/3/12
to
On Tue, 03 Jan 2012 18:32:01 +0100
"Alois Mahdal" <Alois.Mahd...@zxcvb.cz> wrote:

> Sorry for delay.
>
> On Mon, 02 Jan 2012 09:51:14 +0100, Joe <j...@jretrading.com> wrote:
> > Is there anything useful in /var/log/exim4/mainlog? That at least
> > should be in plaintext.
>
>
> Lines in Exim4 sound like purring to me:
>
> -----8<-----
> 2012-01-02 14:09:46 1Rhhe6-00059F-9d <=
> alo...@gebba.aloism.test.local U=aloism P=local S=442
> 2012-01-02 14:09:46 1Rhhe6-00059F-9d =>
> correct....@mydomain.cz <Correct....@mydomain.cz>
> R=smarthost T=remote_smtp_smarthost H=local.gate.cz [10.1.2.3]
> X=TLS1.0:RSA_AES_256_CBC_SHA1:32 DN="C=CZ,ST=Czech
> Republic,L=Town,O=Company,CN=cn.local.gate.cz" 2012-01-02 14:09:46
> 1Rhhe6-00059F-9d Completed ----->8-----
>
> I have obuscated many fields, the adresses there are correct (I also
> tried the e-mail address in lowercase), except for one thing I'm not
> sure about: this part, which is literally:
>
> "R=smarthost T=remote_smtp_smarthost"
>
> I could not find in Exim4 specs what these fields should be.
>
> TIA,
> aL.
>

R is router, T is transport. A router determines where to send a
particular email next, a transport is a software means of achieving
that. Routers and transports may be user-defined for individual
domains or even per recipient, which gives enormous flexibility in
shifting mail around.

This entry is only telling you that delivery has been made successfully
to your local smarthost, local.gate.cz. The next step is to find out
what this server has done with the email, which depends on whether the
server is also yours or you have to ask for logs from someone else.

If the latter, quote them time and date and the message ID beginning
"1Rhhe.." (basically your second line above). The server will definitely
have a log entry which is the 'other half' of your entry above, showing
this email as being accepted, and the message ID should then appear in
one or more additional server log entries where the server tries to send
the message to the next SMTP server in the path to your recipient.

Generally the SMTP protocol is reliable in the communications sense, in
that it will either deliver the mail or it will tell the sender that it
can't, and why not. If mail is disappearing without error messages being
returned to the sender, an anti-spam system is usually the reason.

Joe


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120103181...@jretrading.com

Alois Mahdal

unread,
Jan 3, 2012, 3:40:02 PM1/3/12
to
On Tue, 03 Jan 2012 19:16:49 +0100, Joe <j...@jretrading.com> wrote:
>>
>> "R=smarthost T=remote_smtp_smarthost"
>>
>> I could not find in Exim4 specs what these fields should be.
>>
>> TIA,
>> aL.
>>
>
> R is router, T is transport. A router determines where to send a
> particular email next, a transport is a software means of achieving
> that. Routers and transports may be user-defined for individual
> domains or even per recipient, which gives enormous flexibility in
> shifting mail around.
>

Wow, thanks for insight :-)


> This entry is only telling you that delivery has been made successfully
> to your local smarthost, local.gate.cz. The next step is to find out
> what this server has done with the email, which depends on whether the
> server is also yours or you have to ask for logs from someone else.
>
> If the latter, quote them time and date and the message ID beginning
> "1Rhhe.." (basically your second line above). The server will definitely
> have a log entry which is the 'other half' of your entry above, showing
> this email as being accepted, and the message ID should then appear in
> one or more additional server log entries where the server tries to send
> the message to the next SMTP server in the path to your recipient.

Unfortunately, the server is not mine, and for some reasons, I can't expect
much support. Except when I actually found better solution to the original
problem.


> Generally the SMTP protocol is reliable in the communications sense, in
> that it will either deliver the mail or it will tell the sender that it
> can't, and why not. If mail is disappearing without error messages being
> returned to the sender, an anti-spam system is usually the reason.

So probably antispam filter is throwing them away. (Because my client is
acting weird... Because I've probably done something silly before, or I'm
trying impossible configuration...)


Thankfully, I have found that using -v (verbose) option for tests gives
me enough insight to communication (about what I expected to find after
disabling TLS).

And the lines I like the least are:

SMTP>> EHLO gebba.aloism.test.local
...
SMTP>> MAIL FROM:<alo...@gebba.aloism.test.local> SIZE=1467
AUTH=alo...@gebba.aloism.test.local
...

It seems that exm4 does not rewrite addresses as I wish according to
/etc/exim4/email-addresses:

aloism@localhost: correct...@mydomain.cz
alo...@gebba.aloism.test.local: correct...@mydomain.cz
aloism@gebba: correct...@mydomain.cz
aloism: correct...@mydomain.cz

Neither of these lines work. But manual says:

(sender addresses) "...are rewritten for users that appear to be in
the local domain..."

and my domain (in resov.conf) is different from gebba.aloism.test.local.
Might this be the cause? That "alo...@gebba.aloism.test.local" does not
"appear to be in local domain"?


aL.

--
Alois Mahdal, using Opera's revolutionary e-mail client:
http://www.opera.com/mail/


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/op.v7iy8...@aloism.cz.avg.com

Chris Davies

unread,
Jan 3, 2012, 4:30:03 PM1/3/12
to
Alois Mahdal <Alois.Mahd...@zxcvb.cz> wrote:
> Please, how do I disable TLS in exim4 as a client?

> I tried adding MAIN_TLS_ENABLE = no to exim4.conf.template
> (AND to conf.d/main/03_exim4-config_tlsoptions), but this
> does not affect client.

This is not a yes/no value, it's a defined / not defined value. So by
defining it as "no" you're actually setting it to true. So you should
comment out the line, thus:

# MAIN_TLS_ENABLE = yes

Then you should run these two commands to rebuild the exim configuration
file (/var/lib/exim4/config.autogenerated) and restart exim itself.

update-exim4.conf
invoke-rc.d exim4 restart

Chris


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/qq6ct8x...@news.roaima.co.uk

Alois Mahdal

unread,
Jan 3, 2012, 4:50:02 PM1/3/12
to
On Tue, 03 Jan 2012 21:30:22 +0100, Alois Mahdal
<Alois.Mahd...@zxcvb.cz> wrote:

> It seems that exm4 does not rewrite addresses as I wish according to
> /etc/exim4/email-addresses:
> aloism@localhost: correct...@mydomain.cz
> alo...@gebba.aloism.test.local: correct...@mydomain.cz
> aloism@gebba: correct...@mydomain.cz
> aloism: correct...@mydomain.cz
> Neither of these lines work. But manual says:
> (sender addresses) "...are rewritten for users that appear to be in
> the local domain..."
> and my domain (in resov.conf) is different from gebba.aloism.test.local.
> Might this be the cause? That "alo...@gebba.aloism.test.local" does not
> "appear to be in local domain"?
>

Nope, blind silly human. :-D It's

/etc/email-addresses


Now it works: addresses rewritten, e-mails delivered! :-) (the gate does
not seem to care about thing in "EHLO thing")

Thanks for patience! :)

aL.

PS: Well, not SO silly, I guess there's bug in
http://wiki.debian.org/GmailAndExim4
...going to report...

--
Alois Mahdal using Opera's revolutionary e-mail client:
http://www.opera.com/mail/


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/op.v7i01...@aloism.cz.avg.com

Joe

unread,
Jan 3, 2012, 5:20:01 PM1/3/12
to
On Tue, 03 Jan 2012 21:30:22 +0100
"Alois Mahdal" <Alois.Mahd...@zxcvb.cz> wrote:

>
>
> Thankfully, I have found that using -v (verbose) option for tests
> gives me enough insight to communication (about what I expected to
> find after disabling TLS).
>
> And the lines I like the least are:
>
> SMTP>> EHLO gebba.aloism.test.local
> ...
> SMTP>> MAIL FROM:<alo...@gebba.aloism.test.local> SIZE=1467
> AUTH=alo...@gebba.aloism.test.local
> ...
>
> It seems that exm4 does not rewrite addresses as I wish according to
> /etc/exim4/email-addresses:
>
> aloism@localhost: correct...@mydomain.cz
> alo...@gebba.aloism.test.local: correct...@mydomain.cz
> aloism@gebba: correct...@mydomain.cz
> aloism: correct...@mydomain.cz
>
> Neither of these lines work. But manual says:
>
> (sender addresses) "...are rewritten for users that appear to be
> in the local domain..."
>
> and my domain (in resov.conf) is different from
> gebba.aloism.test.local. Might this be the cause? That
> "alo...@gebba.aloism.test.local" does not "appear to be in local
> domain"?
>
>
Sorry, I can't be of much help in this area, I've never had much to do
with rewriting. The usual thing that needs doing is to change
fr...@computer.domain.com to fr...@domain.com. I use about a dozen
domains, and they are all named in the entry dc_other_hostnames in my
server's update-exim4.conf.conf (this is specific to exim4 on Debian)
and as long as my email client uses a sender address in one of these
domains, no re-writing is necessary. I could be wrong, but I wouldn't
have thought that resolv.conf would be involved, *nix systems do not
generally confuse local DNS search domain with email domain in the way
Windows does. /etc/mailname is probably more relevant.

This may be of some help:
http://lists.netisland.net/archives/plug/plug-2007-01/msg00127.html
Exim4 does have extensive test facilities, where you can get some idea
of what should happen to an email without actually sending it. I
generally only use a small part of it, to test whether emails from some
problematic spam domain will make it past my various acls.

Remember the most basic exim4 configuration gotcha: you can use either
individual small files for configuration in /etc/exim4/conf.d, or one
large one, the /etc/exim4/exim4.conf.template. You decide which in the
initial configuration dialogue, which you can do again with
dpkg-reconfigure exim4. If you make a configuration change in the
wrong place, nothing will happen. Most of us only do it once...

Certainly if you use an invalid domain such as .local and the system
tries to send the email using that domain, many people will reject
it. Most mail servers will check the sender, at least at the level of
the domain. I use exim4 as my system mail server, and it is
configured to do exactly that. I could ask it to check that the
sender actually exists at the sending domain, but that's not really
worth the extra trouble. But if an email fails for this reason, the
SMTP transaction will be interrupted, and the sending server will
report the reason back to the sender.

Joe


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120103221...@jretrading.com

Joe

unread,
Jan 3, 2012, 5:40:03 PM1/3/12
to
On Tue, 03 Jan 2012 22:09:33 +0100
"Alois Mahdal" <Alois....@zxcvb.cz> wrote:

> On Tue, 03 Jan 2012 21:30:22 +0100, Alois Mahdal
> <Alois.Mahd...@zxcvb.cz> wrote:
>
> > It seems that exm4 does not rewrite addresses as I wish according to
> > /etc/exim4/email-addresses:
> > aloism@localhost: correct...@mydomain.cz
> > alo...@gebba.aloism.test.local: correct...@mydomain.cz
> > aloism@gebba: correct...@mydomain.cz
> > aloism: correct...@mydomain.cz
> > Neither of these lines work. But manual says:
> > (sender addresses) "...are rewritten for users that appear to
> > be in the local domain..."
> > and my domain (in resov.conf) is different from
> > gebba.aloism.test.local. Might this be the cause? That
> > "alo...@gebba.aloism.test.local" does not "appear to be in local
> > domain"?
> >
>
> Nope, blind silly human. :-D It's
>
> /etc/email-addresses
>

It's nice when it turns out to be easy, isn't it?

>
> Now it works: addresses rewritten, e-mails delivered! :-) (the gate
> does not seem to care about thing in "EHLO thing")
>

A smarthost won't be too fussy about an authenticated sender, but if
you send direct by unauthenticated SMTP, the receiving server certainly
will be. The HELO/EHLO will need to be a hostname which can be resolved
to an IP address in public DNS. Not necessarily the sender's IP
address, but it won't do any harm if it is.

You may also get away with just a domain name in the HELO, if the
domain's DNS server [incorrectly] resolves this to an IP address.

Joe


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120103223...@jretrading.com

Alois Mahdal

unread,
Jan 4, 2012, 4:00:02 PM1/4/12
to
Hi,

On Tue, 03 Jan 2012 21:59:38 +0100, Chris Davies
<chris-...@roaima.co.uk> wrote:
> [...]
>> I tried adding MAIN_TLS_ENABLE = no to exim4.conf.template[...]
>
> This is not a yes/no value, it's a defined / not defined value. So by
> defining it as "no" you're actually setting it to true. So you should
> comment out the line, thus:
>
> # MAIN_TLS_ENABLE = yes
>
> [...]

Thanks! I hardly would realize this myself :)


However this does not work for me. Actually I believe it was me who
added MAIN_TLS_ENABLE line, so I just removed it, but exim4 still uses
STARTTLS when talking to that smarthost.

Additionally, comments just before ".ifdef MAIN_TLS_ENABLE" already
led me to believe this :

# TLS/SSL configuration for exim as an SMTP server.
# See /usr/share/doc/exim4-base/README.Debian.gz for explanations.

And "2.2.1. Exim 4 as TLS/SSL client" in that README.Debian does not
speak at all about disabling TLS.

"Both exim4-daemon-heavy and exim4-daemon-light support TLS/SSL
using the GnuTLS library and STARTTLS. Exim will use TLS via
STARTTLS automatically as client if the server Exim connects
to offers it."


So I guess that only way how to really disable TLS would be compiling
exim4 *without support* for TLS, which is waaay too scary for me, and
definitely not worth the effort.

Especially when there's this nifty[1] -v option to mail, which actually
solves the original offer in much better way: It simply shows all
the SMTPish information I need to STDERR, as well after STARTTLS as
before.

Thanks,
aL.

1: http://pastebin.com/uN1d9s7v


--
Alois Mahdal, using Opera's revolutionary e-mail client:
http://www.opera.com/mail/


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/op.v7ku6...@aloism.cz.avg.com

Chris Davies

unread,
Jan 5, 2012, 1:30:03 PM1/5/12
to
Alois Mahdal <Alois.Mahd...@zxcvb.cz> wrote:
> However this does not work for me. Actually I believe it was me who
> added MAIN_TLS_ENABLE line, so I just removed it, but exim4 still uses
> STARTTLS when talking to that smarthost.

Ah, yes, sorry. Brain fade; MAIN_TLS_ENABLE controls the server aspect
of TLS, not the client aspect.

Chris


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/qd4ht8x...@news.roaima.co.uk
0 new messages