Bill Hacker wrote:
However, and this is the important point, looking for multiple different
HELO values from a single ip is a _MASSIVELY_ effective way of detecting
apparent ? potential ?
You're slightly too terse for me to tell exactly what you're asking here.
However, looking for
Andrew - Supernews wrote:
However, and this is the important point, looking for multiple different
HELO values from a single ip is a _MASSIVELY_ effective way of detecting
spam sources. If you configure your server to use a variable HELO then
you _will_, sooner or later, find that people end up
Jakob Hirsch wrote:
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
Of course. Look at server_advertise_condition
Ah, I see. I can use this condition to ensure that AUTH is
Nigel Wade wrote:
Of course. Look at server_advertise_condition
Ah, I see. I can use this condition to ensure that AUTH is only
advertised if the connection is encrypted? Is that correct?
That's what the spec says, yes.
The most simple form is:
server_advertise_condition = ${if
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
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
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
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
On Wed, 2006-01-18 at 18:00 +0800, Bill Hacker wrote:
tls_on_connect_ports = 465 : 587 IF and ONLY IF using old-style SSL
instead of STARTTLS. MUA-dependent
there is NO good reason to use tls_on_connect on port 587. this will
only cause interoperability woes.
Note that this does not
On 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
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
Kjetil Torgrim Homme wrote:
On Wed, 2006-01-18 at 18:00 +0800, Bill Hacker wrote:
tls_on_connect_ports = 465 : 587 IF and ONLY IF using old-style SSL
instead of STARTTLS. MUA-dependent
there is NO good reason to use tls_on_connect on port 587. this will
only cause interoperability woes.
Tony Finch wrote:
On 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.
On Wed, 2006-01-18 at 22:53 +0800, Bill Hacker wrote:
Kjetil Torgrim Homme wrote:
there is NO 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
Kjetil Torgrim Homme wrote:
On Wed, 2006-01-18 at 22:53 +0800, Bill Hacker wrote:
Kjetil Torgrim Homme wrote:
there is NO 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!
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
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,
On 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
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
On Wed, 2006-01-18 at 15:53 +, Nigel Wade wrote:
One 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,
On 1/18/06 1:22 AM, Nigel Wade [EMAIL PROTECTED] 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
On 1/18/06 8:09 AM, Kjetil Torgrim Homme [EMAIL PROTECTED] wrote:
Only 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
Now, now...it's only been deprecated for a decade or so, in favor of
STARTTLS. And it will stay in
Bill Hacker wrote:
it is NOT 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
Bill == Bill Hacker [EMAIL PROTECTED] writes:
Bill The first is wasteful of a scarce resource, (IP's) the second
Bill is 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
On 1/18/06 1:22 PM, Kjetil Torgrim Homme [EMAIL PROTECTED] wrote:
upgrade to TLS in HTTP is RFC 2817, btw.
And the wording under Motivation might be called not optimistic about
https: going away within my lifetime (which is more past than future unless
I make 132 or so). It is interesting that
Andrew - Supernews wrote:
Bill == Bill Hacker [EMAIL PROTECTED] writes:
*SNIP*
It is a _NORMAL_ case for the HELO domain to be different to the domain
Not uncommon, yes, Dunno if 'Normal' fits so well w/r MTA's.
*SNIP*
However, and this is the important point, looking for multiple
On Thu, 2006-01-19 at 08:04 +0800, Bill Hacker wrote:
Andrew - Supernews wrote:
It is a _NORMAL_ case for the HELO domain to be different to the domain
Not uncommon, yes, Dunno if 'Normal' fits so well w/r MTA's.
very few properly set up servers will have the domain name as their
hostname.
Bill == Bill Hacker [EMAIL PROTECTED] writes:
It is a _NORMAL_ case for the HELO domain to be different to the
domain
Bill Not uncommon, yes, Dunno if 'Normal' fits so well w/r MTA's.
Less than 50% of the non-spam mail that comes to our support mailbox
from our customers has a HELO
Kjetil Torgrim Homme wrote:
On Thu, 2006-01-19 at 08:04 +0800, Bill Hacker wrote:
Andrew - Supernews wrote:
It is a _NORMAL_ case for the HELO domain to be different to the domain
Not uncommon, yes, Dunno if 'Normal' fits so well w/r MTA's.
very few properly set up servers will have
On 1/18/06 5:20 PM, Andrew - Supernews [EMAIL PROTECTED] wrote:
It surprises you? We've been doing it for ten years; there are parts
of the world in which none of the ISPs have ever heard of Usenet, and
even in the USA there are few ISPs that have an inhouse Usenet service
of usable quality.
30 matches
Mail list logo
