292042Re: smtpd_sender_restrictions some help needed
- Mar 18, 2013On 2013-03-18 17:55, Per olof Ljungmark wrote:
> On 2013-03-18 12:07, Wietse Venema wrote:"although it must suffice that the domain part matches."
>> Per olof Ljungmark:
>>>> I'd recommend separating authenticated from unauthenticated submission.
>>>> Enable submission (port 587) with authentication required, and remove
>>>> permit_sasl_authenticated from the smtpd instance on port 25. For the
>>>> submission port you could enable reject_sender_login_mismatch to
>>>> restrict senders to their own sender address. If you want them to be
>>>> able to use arbitrary addresses for mail sent to local recipients,
>>>> but disallow non-local sender addresses for outbound mail, you'll
>>>> probably have to use a policy service.
>>> Thank you for the tip. Then I have to figure out how to separate the two
>>> rulesets which I yet did not discover in the docs.
>>> Unfortunately we do have clients still using port 465 for sending so not
>>> sure if it is even possible.
>>> No other way to achieve this?
>> Separate your mail streams:
>> MTAs talk to port 25.
>> MUAs talk to port 587 (465 if they are pre-historic).
>> If that is not possible use DNS to separate the streams:
>> MTAs use MX records. Use a separate IP address for MTA service.
>> MUAs use A records. Use a separate IP address for MUA service.
>> Or at least that's what is supposed to happen.
> If we do not implement this case:
> (authenticated client assumed)
> - from nonlocal@ to local-user@local-domain
> Would "reject_sender_login_mismatch" do the job together with
> "smtpd_sender_login_maps"? Here we could match username with MAIL FROM:,
> at least as I understood from a quick read, although it must suffice
> that the domain part matches.
Forget that part, I was thinking backwards...
> Then we just have to fix multi-account MUA's to use different logins for
> different accounts.
> This rule does not have any impact on non-authenticated clients also.
> If this works I'm inclined to use this alternative instead.
- << Previous post in topic