Am 04.09.2015 um 18:50 schrieb Jeremy Harris:
> On 04/09/15 17:22, hw wrote:
>> * in acl_check_rcpt:
>> + accept mail from authenticated for relaying
>> + reject all hosts using connections on 587 without TLS
>> + as before, accept mail from all the hosts the server is relaying for
>>
>> * in acl_check_mail:
>> + deny everything on 587 unless TLS is used
>> Hmmm ... It's a quite weird logic when you think about it, and anything
>> but straightforward. The requirement for authentication is merely
>> implicit. Shouldn't there be a better way to do this? Is there? I'm
>> not exactly fond of convoluted stuff like this.
> I would:
>
> - support 25, 587, 465/ssl-on-connect
Port 25 is for the "normal" traffic, i. e. incoming messages from hosts
on the LAN
and from MTAs in the outside world. Optionally, TLS can be used on 25.
Should I relay imcoming messages from authenticated sources on port 25, too?
> - in authenticators, only offer auth when encrypted
Yes, that's what I'm doing.
> - in mail acl, deny 587 unless encrypted (could go in rcpt but earlier
> is better)
yep
> - in rcpt acl, require auth for any nonlocal destination (relaying)
>
> ... and not support any by-IP implicit authentication at all.
> If forced, bundle with the "real" auth check.
Hm. Require authentication (on port 25) after it has been determined
that the message
would not be delivered locally?
That could be useful. Currently, there is a check in place that denies
delivery to non-local
domains for all sender addresses which are not listed in a file. Of
course, someone could
cheat their way around that by specifying a sender address for which
relaying is allowed.
If I could make it so that the sender address must match the email
address of the user who
has authenticated, nobody could cheat unless they somehow get username
and password
of a user for which relaying is allowed.
How would I do this?
>
> Note that I don't support cram_md5 auth, where there's a better
> argument for permitting non-TLS'd auth. Also, the above doesn't
> enforce that road-warriors encrypt (they might have to use 25 to
> get through...). I've not mentioned auth-by-user-certificate,
> which is another possibility from 4.86 on.
Well, I really don't like all this certificate stuff. The need to support
some arbitrary port which happens not to be blocked might come up some time.
The LOGIN authenticator doesn't seem to be needed. All I'm seeing in
the log file
is that PLAIN is used. Perhaps I should disable the LOGIN one?
