Re: [exim] exim4 Versions above about 4.80 Don't Talk to my …

Top Page
Delete this message
Reply to this message
Author: Martin McCormick
Date:  
To: Exim Users
Subject: Re: [exim] exim4 Versions above about 4.80 Don't Talk to my ISP's smarthost.
Adrian Zaugg via Exim-users <exim-users@???> writes:
> Hi Martin
>
> On Debian you set the outgoing email address map in the file:
>
>         /etc/email-addresses

>
> You can add a line like:
>         martin: martin.m@???

>
> The exim configuration for a simple use case can be made by
>
>         dpkg-reconfigure -plow exim4-config

>
> and answer the questions (chose smarthost) or simply edit
>
>         /etc/exim4/update-exim4.conf.conf

>
> use: dc_eximconfig_configtype='smarthost'
>
> For a port specification like 587 you should use "::", so
>         dc_smarthost='smtp.suddenlink.net::587'
> BTW: Have you tried 587 on smtp.suddenlink.net?

>
> In Debian they tried to make it easy for you and for simple configs you
> should not touch any config file at all. If you have some more demands
> you can use
>         /etc/exim4/conf.d/main/01_exim4-config_listmacrosdefs
> to define macros inside. Debian uses a macro for almost everything. Just
> watch at a config file, e.g.
> /etc/exim4/conf.d/transport/30_exim4-config_remote_smtp_smarthost and
> you see lines like

>
> .ifdef REMOTE_SMTP_SMARTHOST_HOSTS_AVOID_TLS
> hosts_avoid_tls = REMOTE_SMTP_SMARTHOST_HOSTS_AVOID_TLS
> .endif
>
> Instead of editing there, go to
> /etc/exim4/conf.d/main/01_exim4-config_listmacrosdefs and set
>
>         REMOTE_SMTP_SMARTHOST_HOSTS_AVOID_TLS = <whatever comes here>

>
> The value is then used from the macro (=the word in CAPS) in the right
> place. Like this you edit just very few configs and the upgrade runs
> smooth next time. When upgrading Debian compares the original configs
> from the installed package with what's on a system. If there is a
> difference you get those questions "The config file X was changed by you
> or a script. [...]" That's why use the Debian split configuration and
> change as few files as needed.
>
> This unfortunately does not help in your situation.
>
> If you set the port to 465 /etc/exim4/update-exim4.conf.conf, you need
> to add a config file. There is no logic in the stock configuration to
> detect that you are going to send to a TLS only connection.
>
> This is another safe way for upgrading: You could just add a file
> /etc/exim4/conf.d/transport/30_exim4-config_remote_smtp_smarthost_tls
> containing your stanza
>         protocol = smtps
> as the only line (and maybe some comment before). Then

>
>         service exim4 reload

>
> creates the actual config file for exim which resides then
>         /var/lib/exim4/config.autogenerated
> The given configuration is linted before it replaces the
> config.autogenerated, so you get a warning at least for syntax problems.
> You can see in there that your protocol stanza appears in the right
> place belonging to the section "remote_smtp_smarthost:".

>
> This is very Debian specific and does not belong on this list
> actually.... :-)
>
> Regards, Adrian.


    I added the line:


    martin: martin.m@???


and that fixed everything! A thousand thanks.

    In the helpful hints department, I was trying to come up
with a way to cause exim4 to freeze out-going messages in the
queue in order to use the debug flag and get all the good
information about the delivery process that is not normally
needed but valuable when things aren't right.  There are some
good how-tos for freezing individual users' messages but laziness
conquered proper form and I realized that I could simply log in
on the console and pull the Ethernet plug just before sending the
message.  The smarthost is unreachable, then, and the message
gets queued.  Put the plug back and now it can be unfrozen.


I even wrote a little shell script that one runs
under sudo

#!/bin/sh
msg=`mailq |awk '{print $3}'`
if ! test -z $msg;then
exim4 -d -M $msg
fi

    That's because there are two other lines besides the one
with the message ID but field 3 is empty.


    One then gets 400 plus lines that include enough data to
watch the message either be delivered or some error event scuttle
everything.  It was really nice to see all the sender information
match which produces a lot of messages saying that the sender
information matches and things are good.  It's enough to break in
to a happy dance, especially after fighting with this beast for
over 2 weeks.


    The whole process is getting easier every time so again,
thank you and all others who helped.


Martin