Am 07.06.2014 17:25, schrieb Noel Jones: > I wonder why you're just trying to stop SASL from those client... > Why not just use reject_rbl_client (and maybe other restrictions) > before permit_sasl_authenticated to reject all mail from them? If > you're unwilling to accept SASL credentials, why would you accept > anything?
i think the point for different RBL lists for incoming mail and SASL is pretty clear that you have a problem if you are using dialup-lists for your un-authenticated incoming mail flow you can't use the same for submission or better said: typically you have permit_sasl_authenticated in any case before the RBL's and for using RBL's in front of submission they must be much more careful selected and should only contain known abusive IP's but not kill all enduser-dialup-ranges or you end in no longer have any mail-customer in a short * MX: you don't want clients-adsl-xx-xx-xx-some-isp.domain.tld deliver mail * SUBMISSION: you don't want to block that customer ranges completly well, one could say: block them from submission port and don't allow SASL on 25, but that works only if you are a startup beginning from scratch, i condsidered that but it would take weeks and months to explain all customers that they have to fix their client configs and i see even new configured clients using 25 because the idiotic MUA's still default to 25 and burrie the port setting somewhere under "expert" or "extended" settings, so you can't do that if you have hundrets of customers with all sort of devices iPhones and Apple Mail permanently disable SASL auth for unknown reasons or in case of password changes need to re-configure the outgoing mailserver seperated from the incoming creating enough work for a sysadmins lifetime
