I'm in the process of deciding how to configure our mail server to provide
client submission (port 587, and possibly 465). I'm looking for general tips,
and do's and dont's for its configuration. The purpose is to allow authenticated
client submission over SSL from the Internet. We are not able to allow port 25
submission, hence the requirement to setup port 587/465.
I'm currently leaning towards the idea of a separate Exim process handle mail
submission, and for this to relay the mail to the main Exim process for
delivery. I'm hoping that will be easier to setup and maintain than a single
configuration. Are there any gotchas to this approach that I should be aware of
before venturing down this route? What's the perceived wisdom - is it better to
do it this way, or to have a single instance of Exim which handles both normal
SMTP traffic and client submission?
The current version of Exim I use is 4.54, running on RHEL AS4.

Nigel Wade wrote:
I'm currently leaning towards the idea of a separate Exim process handle
mail submission, and for this to relay the mail to the main Exim process
for delivery. I'm hoping that will be easier to setup and maintain than
a single configuration. Are there any gotchas to this approach that I
should be aware of before venturing down this route? What's the
perceived wisdom - is it better to do it this way, or to have a single
instance of Exim which handles both normal SMTP traffic and client
submission?

I'd stick with a single exim.
- Jeremy

Nigel Wade wrote:

I'm in the process of deciding how to configure our mail server to
provide client submission (port 587, and possibly 465). I'm looking for
general tips, and do's and dont's for its configuration. The purpose is
to allow authenticated client submission over SSL from the Internet. We
are not able to allow port 25 submission, hence the requirement to setup
port 587/465.

I'm currently leaning towards the idea of a separate Exim process handle
mail submission, and for this to relay the mail to the main Exim process
for delivery. I'm hoping that will be easier to setup and maintain than
a single configuration. Are there any gotchas to this approach that I
should be aware of before venturing down this route? What's the
perceived wisdom - is it better to do it this way, or to have a single
instance of Exim which handles both normal SMTP traffic and client
submission?

The current version of Exim I use is 4.54, running on RHEL AS4.

There is no problem that I am aware of to doing it with one instance.

Aside from generating and storing and pointing to the appropriate certs,
what we use is:

local_interfaces = <the IP you wish to restrict exim to, if not all present>

daemon_smtp_ports = 25 : 465 : 587 <optionally others>

tls_on_connect_ports = 465 : 587 <IF and NLY IF using old-style SSL
instead of STARTTLS. MUA-dependent>

tls_certificate = /usr/local/etc/exim/certs/<your cert ID<path may
differ for you>

tls_advertise_hosts = *

tls_remember_esmtp = yes <optional. See pros and cons in the Exim
spec.>

auth_advertise_hosts = ${if eq{$tls_cipher}{}{}{*}}

Note that this does not *prevent* an MUA from connecting on port 25, nor
force it to use SSL/TLS if it does so. That is still up to MUA
configuration. But most residential/SH ISP's nowadays will have shut
that door already, so we don't see a need to prevent it. Checking for
'verify domain/recipient' and 'authenticated' and such in acl's prevent
open-relaying, and is needed anyway.

If you want to absolutely block MUA's from use of port 25, then you
would need a second IP, and some DNS work, else MUA's have to specify
the server by IP, not <domain>.<tld>. That works, but limits
failover/fallback/load-sharing methods.

Even so, ISTR (Tony? Philip?) that you can still work in a single Exim
instance by including the IP as well as the port numbers above, as in:

daemon_smtp_ports = <first IP>.25 : <second IP>.465 : <second IP>.587

and (if using SSL instead of STARTTLS):

tls_on_connect_ports = <second IP>.465 : <second IP>.587
- where Exim expects IP.port, not IP:port, i.e. 203.194.153.81.25, not
203.194.153.81:25

Hope that second part, IP.port, is correct

The first part certainly works - it is in production

Best,

Bill

Wed, 18 Jan 2006, Nigel Wade wrote:

I'm in the process of deciding how to configure our mail server to provide
client submission (port 587, and possibly 465). I'm looking for general tips,
and do's and dont's for its configuration.

setup at the start of last year is described at
http://www.cus.cam.ac.uk/~

It has changed a little since then, but the essential design is the same.

Tony.

Nigel Wade wrote:

I'm in the process of deciding how to configure our mail server to provide
client submission (port 587, and possibly 465). I'm looking for general
tips, and do's and dont's for its configuration. The purpose is to allow
authenticated client submission over SSL from the Internet. We are not
able to allow port 25 submission, hence the requirement to setup port
587/465.

It depends on your requirements.
I have only one rule: You have to AUTH before you can submit. I have also
disabled AUTH on port 25, but that's optional.

I'm currently leaning towards the idea of a separate Exim process handle
mail submission, and for this to relay the mail to the main Exim process

I don't see why you should do that. It complicates things unnecessarily.
But that, again, depends on your requirements.

I also saw somebody having port 587 in tls_on_connect, which I think is a
bad idea. While RFC 2476 does not explicitly specify it, all installations
I know of use STARTTLS.

Jakob Hirsch wrote:

Nigel Wade wrote:


>>I'm in the process of deciding how to configure our mail server to provide
>>client submission (port 587, and possibly 465). I'm looking for general
>>tips, and do's and dont's for its configuration. The purpose is to allow
>>authenticated client submission over SSL from the Internet. We are not
>>able to allow port 25 submission, hence the requirement to setup port
>>587/465.

It depends on your requirements.
I have only one rule: You have to AUTH before you can submit. I have also
disabled AUTH on port 25, but that's optional.


>>I'm currently leaning towards the idea of a separate Exim process handle
>>mail submission, and for this to relay the mail to the main Exim process

I don't see why you should do that. It complicates things unnecessarily.
But that, again, depends on your requirements.

I also saw somebody having port 587 in tls_on_connect, which I think is a
bad idea. While RFC 2476 does not explicitly specify it, all installations
I know of use STARTTLS.

DTS. (Depends The Situation).

We have the "luxury" of not having to cater to WinWoes or Apple 'native'
alleged-MUA's, and use different SSL arrival ports for:
- faster setup than STARTTLS
- helping 'ban' MUA's we don't want to support anyway
- selecting different acl routing rules for different user groups

Admittedly non-standard, I will agree, but derned handy ;-)

Bill

Bill Hacker wrote:

>bad idea. While RFC 2476 does not explicitly specify it, all
>installations I know of use STARTTLS.

"on this port", that is.

We have the "luxury" of not having to cater to WinWoes or Apple 'native'
alleged-MUA's, and use different SSL arrival ports for:
- faster setup than STARTTLS

I use the smtps port (465) for this.
- helping 'ban' MUA's we don't want to support anyway

By requiring immediate TLS instead of STARTTLS? Interesting. Last time I
checked, E supported only the former of both.
- selecting different acl routing rules for different user groups

Depending on the incoming port? Sounds not very reliable.
Anyway, I'd rather use some arbitrary port for this than abuse a
well-known port.

Wed, 2006-01-18 at 18:00 +0800, Bill Hacker wrote:
tls_on_connect_ports = 465 : 587 <IF and NLY IF using old-style SSL
instead of STARTTLS. MUA-dependent>

there is N good reason to use tls_on_connect on port 587. this will
only cause interoperability woes.

Note that this does not *prevent* an MUA from connecting on port 25, nor
force it to use SSL/TLS if it does so.

or vice versa for MTA's connecting to 587. we actually experienced that
yesterday, an MTA set up to use port 587, ostensibly for security
purposes! luckily we had put in a check for this and deny
unauthenticated sending on ports other than 25 (we support 465 and 587
as MSA).

Jakob Hirsch wrote:

Bill Hacker wrote:

bad idea. While RFC 2476 does not explicitly specify it, all
installations I know of use STARTTLS.

"on this port", that is.


>>We have the "luxury" of not having to cater to WinWoes or Apple 'native'
>>alleged-MUA's, and use different SSL arrival ports for:

faster setup than STARTTLS

I use the smtps port (465) for this.

So do we.

And several others I edited-out

No shortage of ports

helping 'ban' MUA's we don't want to support anyway

By requiring immediate TLS instead of STARTTLS? Interesting. Last time I
checked, E supported only the former of both.

I wouldn't expect that to be consistent over the many years/versions of
/E.

of our users actually *does* have a WinBox, but is intelligent enuf
to not use an MS MUA.
browser (far more easily banned)

selecting different acl routing rules for different user groups

Depending on the incoming port? Sounds not very reliable.

Why so? Incoming ports tend to stay where you put 'em. takes
more work
Helps with getting the correct outbound helo set up for a virtual-domain
system, permits penalizing or srutinizing shoddy MUA's w/o totally
prohibiting them, (apply SA and ClamAV to certain S/MUA's in both
directions),

Anyway, I'd rather use some arbitrary port for this than abuse a
well-known port.

We do that also. And 'well known' is exactly that, and not a thing more.

When a client has a really draconian ISP/corporate firewall, we even
provide secure SMTPSA on port 80 or 443.
Seldom blocked ;-)

Diff'rent strokes

Best,

Bill

Wed, 18 Jan 2006, Jakob Hirsch wrote:

Bill Hacker wrote:

- selecting different acl routing rules for different user groups

Depending on the incoming port? Sounds not very reliable.
Anyway, I'd rather use some arbitrary port for this than abuse a
well-known port.

Another way of doing this would be to get users to setup their MUAs using
host names like fanf2.smtp.hermes.cam.ac.uk so that the DNS can be used to
divide users into classes. ( do this for IMAP but not SMTP.)

Tony.

Kjetil Torgrim Homme wrote:

Wed, 2006-01-18 at 18:00 +0800, Bill Hacker wrote:

>>tls_on_connect_ports = 465 : 587 <IF and NLY IF using old-style SSL
>>instead of STARTTLS. MUA-dependent>

there is N good reason to use tls_on_connect on port 587. this will
only cause interoperability woes.

See below.


>>Note that this does not *prevent* an MUA from connecting on port 25, nor
>>force it to use SSL/TLS if it does so.

or vice versa for MTA's connecting to 587.

Not so!

Aside from matching the protocol, they would have to be able to
authenticate with
port-specific SQL-DB stored multi-part UID's and passwords that do not
resemble
local_part@domain, nor are they the same UID/PWD's used for webmail, PP
or IMAP.

we actually experienced that
yesterday, an MTA set up to use port 587, ostensibly for security
purposes! luckily we had put in a check for this and deny
unauthenticated sending on ports other than 25 (we support 465 and 587
as MSA).

You just disproved your own first point, above, in showing that the
'interoperability woes' issue can contribute to preventing unexpected
abuse, at the very least by caling attention to it.

use of 587 fits precisely our setup for specific-client MUA's. And
no others.

Not proselytizing, but 'standards' apply to the part we do NT control
(our MTA-MTA environment is very much more gracious).

w/r MUA's, TH, its 'our servers, our rules'. And even ' chosen MUA's'.

But we do only bespoke, corporate mx, some with as few as half-a-dozen
accounts, not public/all-comers ISP/ASP services, so, as said, a
"luxury". ;-)

Bill

Tony Finch wrote:
Wed, 18 Jan 2006, Jakob Hirsch wrote:


>>Bill Hacker wrote:
>>
>>
selecting different acl routing rules for different user groups
>>
>>Depending on the incoming port? Sounds not very reliable.
>>Anyway, I'd rather use some arbitrary port for this than abuse a
>>well-known port.

Another way of doing this would be to get users to setup their MUAs using
host names like fanf2.smtp.hermes.cam.ac.uk so that the DNS can be used to
divide users into classes. ( do this for IMAP but not SMTP.)

Tony.

Good as far as it goes. Perhaps I'll try that (also), as we do control
the DNS.

Thanx,

Bill

Wed, 2006-01-18 at 22:53 +0800, Bill Hacker wrote:
Kjetil Torgrim Homme wrote:
there is N good reason to use tls_on_connect on port 587. this will
only cause interoperability woes.

[] an MTA set up to use port 587, ostensibly for security
purposes! luckily we had put in a check for this and deny
unauthenticated sending on ports other than 25 (we support 465 and 587
as MSA).

You just disproved your own first point, above, in showing that the
'interoperability woes' issue can contribute to preventing unexpected
abuse, at the very least by caling attention to it.

uh. this doesn't make any sense. port 587 is to be used to
authenticated SMTP. it should start out unencrypted. what happens
after initial EHL handshake will depend on negotiations between server
and client. it is NT required to use STARTTLS, many prefer to use
CRAM-MD5 or similar schemes which aren't vulnerable to sniffing.

use of 587 fits precisely our setup for specific-client MUA's. And
no others.

Not proselytizing, but 'standards' apply to the part we do NT control
(our MTA-MTA environment is very much more gracious).

yes, your system, your rules. if you want to make configuration harder
for your clients, feel free. but it is bad advice to pass out to
others.

Kjetil Torgrim Homme wrote:

Wed, 2006-01-18 at 22:53 +0800, Bill Hacker wrote:

>>Kjetil Torgrim Homme wrote:
>>
there is N good reason to use tls_on_connect on port 587. this will
only cause interoperability woes.

[] an MTA set up to use port 587, ostensibly for security
purposes! luckily we had put in a check for this and deny
unauthenticated sending on ports other than 25 (we support 465 and 587
as MSA).
>>
>>You just disproved your own first point, above, in showing that the
>>'interoperability woes' issue can contribute to preventing unexpected
>>abuse, at the very least by caling attention to it.

uh. this doesn't make any sense. port 587 is to be used to
authenticated SMTP. it should start out unencrypted.

Why should it not be encrypted from the outset?
'Coz there are inflexible MUA's? Easily fixed.

what happens
after initial EHL handshake will depend on negotiations between server
and client.

if you do not want it to begin life in an SSL 'tunnel'. We do.

it is NT required to use STARTTLS, many prefer to use
CRAM-MD5 or similar schemes which aren't vulnerable to sniffing.

How, pray tell, is the know-long-ago-compromised MD5 less 'vulnerable'
than the
current higher-level releases of SSL/TLS?


>use of 587 fits precisely our setup for specific-client MUA's. And
>>no others.
>>
>>Not proselytizing, but 'standards' apply to the part we do NT control
>>(our MTA-MTA environment is very much more gracious).

yes, your system, your rules. if you want to make configuration harder
for your clients, feel free. but it is bad advice to pass out to
others.

It might indeed be 'bad advice' to pose it as an alternative *standard*,
or even
generally attractive to public-serving ISP/ASP's.

corporate/institutional admins, of which we have many here, may
find it more useful.
We have many good reasons to control end-user environment, most of them
cost-driven
as well as security-driven.

Configuration is no 'harder' for the client than following any other set
of instructions.
(in any case, we actually do it for nearly all of them anyway -
'corporate', remember).

They put <somethingin box 'a', <something elsein box 'b', etc. in
either case,
and 'convenience' is fully transparent once the setup is made.

Run your environment however you are allowed to/see fit/can justify

"Pardon him, Theodotus"

Best,

Bill

Bill Hacker wrote:

selecting different acl routing rules for different user groups
>Depending on the incoming port? Sounds not very reliable.
Why so? Incoming ports tend to stay where you put 'em.

Sure, but client configurations tend to change all the time. And what
stops people from using one the other many ports you provide?

Helps with getting the correct outbound helo set up for a virtual-domain

helo is not correlated to the sender domain (unless you want to disguise
poorly). It should resolve to the connecting IP address, and vice versa,
which could be nasty if use many different helos.

Well, I hope your mail system works better than your homepage

Thanks everyone. It seems I have quite a lot of information to be getting on
with. I just want to follow up on some points

Jakob Hirsch wrote:
Nigel Wade wrote:


>>I'm in the process of deciding how to configure our mail server to provide
>>client submission (port 587, and possibly 465). I'm looking for general
>>tips, and do's and dont's for its configuration. The purpose is to allow
>>authenticated client submission over SSL from the Internet. We are not
>>able to allow port 25 submission, hence the requirement to setup port
>>587/465.

It depends on your requirements.
I have only one rule: You have to AUTH before you can submit. I have also
disabled AUTH on port 25, but that's optional.

Port 25 isn't an option for us, it's already blocked. That's one of the reasons
for enabling the submission ports.


>>I'm currently leaning towards the idea of a separate Exim process handle
>>mail submission, and for this to relay the mail to the main Exim process

I don't see why you should do that. It complicates things unnecessarily.
But that, again, depends on your requirements.

thing which puzzles me is that everyone is of the opinion that a single
Exim, with everything rolled into one config. is simpler. I don't get this. I
really would have expected it to be simpler and cleaner, to separate the roles,
with less chance of rules for one role interfering with the other. I'd already
looked at Tony's config. for Exim at Cambridge, and those multiple
"personalities" and the multiplicity of ACLs was one reason I thought separating
the roles would make life easier.

Also, with separate processes, it should be possible to completely separate the
mail submission from the MTA functions, so I can shut down either submission or
MTA roles without affecting the other, and can test each in isolation.

Am I missing something obvious, which would make this more complicated than I
think it might be?

I also saw somebody having port 587 in tls_on_connect, which I think is a
bad idea. While RFC 2476 does not explicitly specify it, all installations
I know of use STARTTLS.

If you rely on STARTTLS, is it possible to enforce STARTTLS *before*
authentication, so some user doesn't configure their MUA to send their
credentials unencrypted? Since this is to allow non-local submission I don't
want this information being sent unencrypted.

Nigel Wade wrote:

If you rely on STARTTLS, is it possible to enforce STARTTLS *before*
authentication, so some user doesn't configure their MUA to send their
credentials unencrypted? Since this is to allow non-local submission I don't
want this information being sent unencrypted.

Yes, server_advertise_condition in the authenticators is expanded, so
you can test for TLS there.

#SECTauthexiser
- Marc

Wed, 2006-01-18 at 23:33 +0800, Bill Hacker wrote:
Kjetil Torgrim Homme wrote:
uh. this doesn't make any sense. port 587 is to be used to
authenticated SMTP. it should start out unencrypted.

Why should it not be encrypted from the outset?
'Coz there are inflexible MUA's? Easily fixed.

there were no Internet standards starting in encrypted mode until the
publication of SSH as RFC 42504256. so this month, this piece of
trivia changed, but it didn't change the philosophy of IETF in the
design of Internet protocols. LDAP, IMAP, SMTP, etc. etc -- it all
starts unencrypted and negotiates afterwards.

what happens
after initial EHL handshake will depend on negotiations between server
and client.

if you do not want it to begin life in an SSL 'tunnel'. We do.

fair enough, but this is at odds with Internet standards

it is NT required to use STARTTLS, many prefer to use
CRAM-MD5 or similar schemes which aren't vulnerable to sniffing.

How, pray tell, is the know-long-ago-compromised MD5 less 'vulnerable'
than the
current higher-level releases of SSL/TLS?

I didn't make such a claim. (and CRAM-MD5 is not compromised by MD5
collision attacks, anyway.)

Jakob Hirsch wrote:

Bill Hacker wrote:

selecting different acl routing rules for different user groups

Depending on the incoming port? Sounds not very reliable.
>>
>>Why so? Incoming ports tend to stay where you put 'em.

Sure, but client configurations tend to change all the time.

Not unless we choose to install new ones.

And what
stops people from using one the other many ports you provide?

The fact that the system will not authenticate them seems to work fine


>>Helps with getting the correct outbound helo set up for a virtual-domain

helo is not correlated to the sender domain (unless you want to disguise
poorly).

NT. Quite the reverse. We want it to *match* the sender's {domain}.

>It should resolve to the connecting IP address, and vice versa,
which could be nasty if use many different helos.

Not under the sending MTA's control in a multi-domain environment.

Where the DNS carries multiple PTR records for one IP, as it may for
virtual hosting,
any one of the several valid domain.tld may be furnished in response to
a lookup of the IP.

Call that 'challenge NE', traditionally solved by using up a separate
IP for each domain, R using a 'none of the above' PTR record for the mx
hosting many virtual domains.

The first is wasteful of a scarce resource, (IP's) the second is not
optimal if the far-end is looking at the sender's {domain} against the
helo (as we ourselves do).

That we *can* control with 'helo_data' - to at least match the helo to
our sender's {domain}. 'Challenge TW'.

Look at headers on my posts over time and note that the same server IP
may have been seen as any one of three domains.
We are still working on that. Meanwhile, at least the helo matches the
domain of the e-mail address.

Exim would score a 'mismatch' on the helo otherwise, but does NT
(inherently) care so much about 'challenge NE', the sender_host_address
matching the forward-lookup of the valid PTR found from it - only that
there IS one.

All that 'motion', basically so that we can satisfy the likes of AL and
our own rather picky Exim servers - without using up more IP's than the
'traffic' would justify.

Trying to get as 'standard' as we can on the 'public' side.

A bit of 'weird' on the MUA side is part of how we can do that reliably.

belt and braces

Well, I hope your mail system works better than your homepage

What homepage?

Bill

Wed, 2006-01-18 at 15:53 +0000, Nigel Wade wrote:
thing which puzzles me is that everyone is of the opinion that a single
Exim, with everything rolled into one config. is simpler. I don't get this. I
really would have expected it to be simpler and cleaner, to separate the roles,
with less chance of rules for one role interfering with the other. I'd already
looked at Tony's config. for Exim at Cambridge, and those multiple
"personalities" and the multiplicity of ACLs was one reason I thought separating
the roles would make life easier.

if you want the policy "accept everything and bounce later", I say
spring for separate configuration. I have however grown quite fond of
the submission port giving the negative answer to RCPT. with my MUA,
Evolution, it will stop the sending attempt immediately, and allow me to
fix the recipient list, and thus sparing some recipients from receiving
two copies, one with the faulty address list, and one correct later.

we try to reuse configuration, anyway. it's quite important to keep
them internally consistent to avoid loops :) we have many servers and
15 different exim.conf which make extensive use of .include.

Kjetil Torgrim Homme wrote:

*SNIP*

there were no Internet standards starting in encrypted mode until the
publication of SSH as RFC 42504256. so this month, this piece of
trivia changed, but it didn't change the philosophy of IETF in the
design of Internet protocols. LDAP, IMAP, SMTP, etc. etc -- it all
starts unencrypted and negotiates afterwards.

Heavy sigh

Find a (probably *BSD) box that has been running for six or seven years,
find these in /etc/services:

smtps, spop, pop3s, imaps, etc.

Change to Requests For Comment are never-ending.
Ports still work as they are told (locally).

Support for these old standbys in for example, Mozilla Mail, and scads
of older MUA's wasn't added yesterday

All STARTTLS brought to the party was the ability for a 'stranger' to
seek one standard port, then adapt to what was offered by 'negotiation'.

That has immense value on port 25, and 'public facing' MTA's less so on
other ports or private/internal MTAs.

what happens
after initial EHL handshake will depend on negotiations between server
and client.
>>
>if you do not want it to begin life in an SSL 'tunnel'. We do.

fair enough, but this is at odds with Internet standards

Depends on which rev/age of which Request For Comment you choose.

Everything is in compliance with some, at odds with others - current or
otherwise.
'Internet Standard' is a goal - and a desireable one generally - but not
a reality.

TWX, TELEX, and RTTY, TH, *did* have 'standards'. Most were very
rigid ones, too.
Likewise SNA, HDLC, X.25, X.75, and so on. But we had less room for
innovation in those days.

Few RFC's get adopted immediately, entirely, or as widely as they might be.
Look at the discussion on RFC-mandated domain_literals (which we
support, but few others here do, BTW).

it is NT required to use STARTTLS, many prefer to use
CRAM-MD5 or similar schemes which aren't vulnerable to sniffing.
>>
>>How, pray tell, is the know-long-ago-compromised MD5 less 'vulnerable'
>>than the
>>current higher-level releases of SSL/TLS?

I didn't make such a claim. (and CRAM-MD5 is not compromised by MD5
collision attacks, anyway.)

Be that as it may, (not betting either way) plaintext inside of a
pre-existing SSL tunnel is *way* easier to use, and no less secure, *so
long as* you do not permit 'fallback' to unencrypted.

Forcing SSL/TLS-on-connect by port 'up front' in the configure guards
against that possibilty, whereas an obscure coding error in your
authenticators might permit fallback to plantext with 'negotiated' TLS.

Belt and braces

YMMV,

Bill

Bill

Thu, Jan 19, 2006 at 12:54:34AM +0800, Bill Hacker wrote:
Kjetil Torgrim Homme wrote:
[>Bill]
[ Kjetil]

All STARTTLS brought to the party was the ability for a 'stranger' to
seek one standard port, then adapt to what was offered by 'negotiation'.

That has immense value on port 25, and 'public facing' MTA's less so on
other ports or private/internal MTAs.

STARTTLS is almost, but not quite entirely, useless on port 25.

>fair enough, but this is at odds with Internet standards
Depends on which rev/age of which Request For Comment you choose.

How much do you know about the IETF Standards Track? This comment would
appear to suggest that it's not a lot. (Note here the difference between:
STANDARD, PRPSED STANDARD, RFC, Internet-Draft).

Everything is in compliance with some, at odds with others - current or
otherwise.
'Internet Standard' is a goal - and a desireable one generally - but not
a reality.

These comments are meaningless.

it is NT required to use STARTTLS, many prefer to use
CRAM-MD5 or similar schemes which aren't vulnerable to sniffing.
How, pray tell, is the know-long-ago-compromised MD5 less 'vulnerable'
than the current higher-level releases of SSL/TLS?
>I didn't make such a claim. (and CRAM-MD5 is not compromised by MD5
>collision attacks, anyway.)
Be that as it may, (not betting either way) plaintext inside of a
pre-existing SSL tunnel is *way* easier to use, and no less secure, *so
long as* you do not permit 'fallback' to unencrypted.

Well, well, an interesting idea of an argument, so I'll jump in. of
interest, the certificate you present as a server cert? It might either
be (a) self-signed or (b) signed by a certificate authority. If the latter
I'd be very surprised if the signature algorithm wasn't RSA-MD5 (and
collision certificates *have* been generated). If (a) then how does SSL/TLS
actually protect you (think man-in-the-middle here)?

Forcing SSL/TLS-on-connect by port 'up front' in the configure guards
against that possibilty, whereas an obscure coding error in your
authenticators might permit fallback to plantext with 'negotiated' TLS.

Well, this is all very well, but let's suppose, for a second, that I have
a work laptop using your service to send mail from my work address, and
some random system to send mail from a home address or vanity domain. I
have to authenticate to both. Why make yours different (yes, sure you can)
from this, just so actually it's more pain for me in the end? This sort of
thing is not actually a win for your customers, and it's probably not a win
for you, in terms of your support calls, but hey, you can just carry on
living in your own planet, because it does only affect your customers
(unlike, say, running an open relay).

Cheers

MBM

Nigel Wade wrote:

I'm currently leaning towards the idea of a separate Exim process handle
mail submission, and for this to relay the mail to the main Exim process
>I don't see why you should do that. It complicates things unnecessarily.
>But that, again, depends on your requirements.
thing which puzzles me is that everyone is of the opinion that a
single Exim, with everything rolled into one config. is simpler. I don't

As I said, it depends on your requirements (which you didn't specify). If
you want to treat submissions that much different, you may be better off
using a seperate instance. But I'd bet it doubles many parts of the MTA
config.

If you rely on STARTTLS, is it possible to enforce STARTTLS *before*
authentication, so some user doesn't configure their MUA to send their

course. Look at server_advertise_condition and the wiki examples.

Bill Hacker wrote:

>it is NT required to use STARTTLS, many prefer to use
>CRAM-MD5 or similar schemes which aren't vulnerable to sniffing.
How, pray tell, is the know-long-ago-compromised MD5 less 'vulnerable'
than the current higher-level releases of SSL/TLS?

It is surely not (and Kjetil did not write this), but MD5 is not
"compromised". There was a collision attack published in 2004, practical
consequences are yet to be proven (AFAIK).

I'd rather use TLS, of course.

Kjetil Torgrim Homme wrote:
design of Internet protocols. LDAP, IMAP, SMTP, etc. etc -- it all
starts unencrypted and negotiates afterwards.
Err, there's a $1s counterpart for every protocol you listed, and there
are pop3s, imaps, nntps, https (which has no STARTTLS, TTBMK).

Jakob Hirsch wrote:

Kjetil Torgrim Homme wrote:


>>design of Internet protocols. LDAP, IMAP, SMTP, etc. etc -- it all
>>starts unencrypted and negotiates afterwards.

Err, there's a $1s counterpart for every protocol you listed, and there
are pop3s, imaps, nntps, https (which has no STARTTLS, TTBMK).

ACK.

But in a manner of speaking an https (variant) can have comparable
behaviour.

ISTR that 'modern' http has a provision for specifying 'en clair' which
of several possible domains it seeks on a given IP, such that the server
can (among other things) offer up a matching cert - otherwise
historically a PITA for multi-domain servers on one IP.

'' ALServer 'clusters' also did something similar via effectively
transparent routing a single external IP to multiple backend ALServers
over unix sockets, & Squid *might* be able to do something similar if
breathed on heavily. Likewise Exim

Details escape me, as implementation was/is rare, and it goes against
the 'standards' vs simpler use of 'wildcard' or multi-domain certs;-)

Bill

Bill Hacker wrote:

Helps with getting the correct outbound helo set up for a virtual-domain
>helo is not correlated to the sender domain (unless you want to disguise
NT. Quite the reverse. We want it to *match* the sender's {domain}.

Yes, you *want*, but there's no point in doing that.

The first is wasteful of a scarce resource, (IP's) the second is not
optimal if the far-end is looking at the sender's {domain} against the
helo (as we ourselves do).

Let me check if I understand right: You check if the sender domain matches
the helo domain? So following would invalid in your eyes?

EHL example.net
MAIL FRM:<someone (AT) example (DOT) com>

If this is what you mean, you are wrong.

>Well, I hope your mail system works better than your homepage
What homepage?

http://www.conducive.org/

Jakob Hirsch wrote:
Bill Hacker wrote:

*SNIP*

Let me check if I understand right: You check if the sender domain matches
the helo domain? So following would invalid in your eyes?

EHL example.net
MAIL FRM:<someone (AT) example (DOT) com>

If this is what you mean, you are wrong.

That is what I mean, and earns such a sender a 'demerit' of 1 point:
An outright deny/drop/discard on NE such point would be 'wrong'.
See comments below:

# HEL: IF HEL verification fails THEN prep message.
# *CANNT REJECT YET* Too many Mis-matched ID's, some of our own
included!
#
warn
condition = ${if !def:acl_c1 {true}{false}}
!verify = helo
set acl_c1 = X-HELWarning: Remote host $sender_host_address \
${if def:sender_host_name {($sender_helo_name) }}\
is cross-dressed as $sender_helo_name !!!
log_message = H5 $acl_c3 has mismatched ID's in HEL/EHL greeting.
set acl_c2 = $acl_c2 Mismatched HEL=1
set acl_c5 = ${eval:$acl_c5 + 1}

But this is but one of several tests for 'good practice'.

Here is another 'soft' fail that can add to the score and eventually
become a 'hard' fail:

# FRM_6: IF FAIL sender_verify THEN prep message AND add to header.
#
warn
!verify = sender/defer_ok/callout=10s,defer_ok
set acl_c2 = $acl_c2 Sender Verify = $sender_verify_failure
$sender_address_data
set acl_c5 = ${eval:$acl_c5 + 1}
log_message = F6 $acl_c3 failed sender verify at
$sender_verify_failure for $sender_address $sender_address_data

And another (held-off until 'DATA' phase to avoid 'cost' of an external
lookup if already rejected):

# DATA_6B: IF host rDNS lookup fails THEN warn AND flag for later NT
delay.
#
warn
log_message = C5 $sender_host_name $sender_host_address failed rDNS
lookup with score of $acl_c5 for $acl_c2
!condition = ${if eq{$acl_m4}{0}}
!condition = +relay_from_hosts
!verify = reverse_host_lookup
message = X-DNS-Broken-Warn: rDNS lookup failed for
$Sender_host_address
set acl_c2 = $acl_c2 Missing rDNS PTR=1
set acl_c5 = ${eval:$acl_c5 + 1}

Too many such 'points' regardless of the 'mix', on the same connection
can very accurately ID a zombie or spambot, can be tested against a
global, per-domain, or per-user threshold with near-zero false alarms,
and a very much lightened load on resource-intensive SA.

We have been saving and checking the rejections since last ,
falsing is NT a problem, and spam is miniscule.
SA catches the 'complex' ones, but such rules as above get the majority
before they ever reach it.

YMMV

Well, I hope your mail system works better than your homepage
>>
>>What homepage?

http://www.conducive.org/

Ah! 'Cobbler's children going barefoot, as it were when I have time

precisa.ch better represents our work

Bill

"Bill" == Bill Hacker <wbh (AT) conducive (DOT) orgwrites:

BillThe first is wasteful of a scarce resource, (IP's) the second
Billis not optimal if the far-end is looking at the sender's
Bill{domain} against the helo (as we ourselves do).

Trying to match the sender domain against the helo is an exercise in
futility, and more importantly, it's spreading a very dangerous meme
amongst the authors of some defective mail software (of which IPSwitch
Imail is the most egregious, but there are many other examples).

It is a _NRMAL_ case for the HEL domain to be different to the domain
of the envelope sender. (The examples are endless; forwarded mail, mail
from @msn addresses coming from hotmail.com servers, mail from any of
several million domains outsourced to large outsourcers like or
the old Critical Path hosted service; the list goes on.)

It is also not a good criterion for whitelisting; spam sent from zombie
machines frequently uses a HEL matching the envelope sender.

However, and this is the important point, looking for multiple different
HEL values from a single ip is a _MASSIVELY_ effective way of detecting
spam sources. If you configure your server to use a variable HEL then
you _will_, sooner or later, find that people end up blocking you as a
result. If you've never used this method of detecting spam (and it takes
a fairly large mail flow into several domains to really do it right) you
would not believe how amazingly effective it can be.

BillThat we *can* control with 'helo_data' - to at least match the
Billhelo to our sender's {domain}. 'Challenge TW'.

You should not even try. You should have NE_ PTR record for an IP
doing outgoing mail, and the HEL should be (a) fixed, and (b) should
match that PTR record.

BillAll that 'motion', basically so that we can satisfy the likes
Billof AL and our own rather picky Exim servers

AL doesn't require that the HEL match the envelope sender and never
will. I'd be willing to bet that they look for variable HEL values
from a given IP, though.

If you configure your MTA to behave in ways characteristic of spam
zombies simply in order to satisfy your _own_ broken filtering rules,
then you should expect problems getting your mail delivered.

Wed, 2006-01-18 at 18:28 +0100, Jakob Hirsch wrote:
Kjetil Torgrim Homme wrote:

design of Internet protocols. LDAP, IMAP, SMTP, etc. etc -- it all
starts unencrypted and negotiates afterwards.

Err, there's a $1s counterpart for every protocol you listed, and there
are pop3s, imaps, nntps, https (which has no STARTTLS, TTBMK).

HTTPS was a Netscape invention, and it filled a great need, so the
method was quickly applied to other protocols. IETF was never satisfied
with using two ports for every protocol, however, so the recommended way
of going encrypted is the relevant protocol's STARTTLS equivalent.

upgrade to TLS in HTTP is RFC 2817, btw.