Re: [exim] Problem with TLS connection

Hill Ruyter wrote:
> Hello again
>
> Whenever I make a change to the config I do the following, I had assumed it
> was the correct processŠ
>
> update-exim4.conf
> Invoke-rc.d exim4 stop
> Invoke-rc.d exim4 start

That or 'restart' or even 'reload' if such options exist *should* have
caused a re-read of the ~/configure file.

Assuming you didn't simply forget to actually DO it once upon a time...

;-)

.. there are sometimes situations where something breaks - including
updates that move the binary and the like, damaed infrastructure, daemon
NOt started perviosly with sais script, yadda, yadda - and the running
process does NOT respond to the script.

useful to do a 'top -U <the exim daemon-runner's UID>'

Also Go Ogle 'pidof' and 'killall' fro soemthign less messy than a ps
waux and kill -HUP or kill -9.

> If this is wrong then please do let me know but I was sure it was enough to
> initiate any changes to the configuration template.
>

It is correct as far as it goes. Something went pear-shaped.

>
> In reference to the comments by Ian
>
> I am really confused by the proper use of ports. I was using 465 for my SSL
> connections until someone told me that was not the correct port to use for
> SMTP over SSL/TLS

465 WAS used for SSL (AND NOT starttls) for smtp submission for an old
Dog's lifespan, but was never granted 'official' status.

Worse, several years ago it WAS granted offical status for a
Cisco-proprietayr serve not even related to smtp.

AFAIK, there are very few (if any) current MUA that still have no other
option, so there is no point in fighting that. Consider 465 gone..

> and that I should be using 587 so I changed my config,
> firewalls etc because I have a wish to do things properly.
>

587 DOES have official standing for smtp submission.

'Properly' - or more accurately 'preferably' - with SSL/TLS using the
full TLS handshake AND NOT always-on SSL with its own (legacy) style of
negotiation. And in any cse - *encrypted*. Please.

As it is an in-client-community AND NOT 'public facing' service port,
(eg: YOUR users, not the entire Earth) it CAN legitimately be used with
any protocol you wish.

Some (guilty as charged [1]) choose to use it with old-style SSL
(tls_on_connect) .. but that requires configuring all Luser's MUA to
match. Now AND in future.

> I am not running an ISP or anything like this, it is just my mail server
> for a few business accounts for my own business and a few accounts for
> family and friends across about 5 domains each with about 5 accounts.
>
> Is there a definitive answer to what port I should be using to make SMTP
> connections over TLS
>

*snip*

587 with the 'conventional' setting AND NOT 'tls_on_connect' is the road
most traveled and should give you the least admin workload at MTA and
MUA [1]

FWIW - port 25 with STARTTLS is also widely used for AUTH...

HOWEVER - 25 is a Very Bad Choice for end-user submission for two reasons;

- More and more wise, thoughtful, or burn-scarred connectivity IP either
block outbound from within their IP user pools TO any far-end port 25
ELSE capture and redirect such traffic to their OWN MTA. If that doesn't
bite your users at home or office, it may well do when they are
traveling. But .. as it stops an entire species of WinCrobes cold and
reduces their risk of their entire CIDR or <domain>.<tld> being
blacklisted, it is a growing movement.

- Exim (and other) filtering is far easier and can be done earlier when
ALL port 25 arrivals are expected to be peer MTA submitting from
fixed-IP with proper PTR RR and other credentials (Go Ogle rDNS for pors
and cons), but otherwise not needing or being offered AUTH...

...AND

... port 587 arrivals are NOT checked for any such IP/DNS credentials
but ARE required to be known to you (UID) and AUTH as such (PWD). And/or
SSL cert matchup...

Simpler alc's, earlier shedding of hodlums, easier to NOT accidentally
block Lusers.


HTH,

Bill

[1] That said, IF 'tcpdump -i' just happens to show botnets chewing up
your for-fee bandwidth rations by banging on the door in hopes of
brute-forcing a UID:PWD combo, THEN changing MTA *and* MUA to old-style
SSL with 'tls_on_connect' can save some money and grief.

You probably won't need that unless your servers are on China's
doorstep, hop-count-wise. As mine are....