Zitat von Viktor Dukhovni <postfix-us...@dukhovni.org>:
On Fri, Sep 13, 2013 at 11:45:54AM +0900, Jorgen Lundman wrote:However, quite often the 3rd party involved uses software that can use pipelining, and simply keeps sending mail, even though the SMTPAuth account has been stopped.What you are calling "pipelining" is more properly called connection caching or message piggy-backing. A single SMTP connection is used to deliver multiple messages.Naturally, we can simply restart Postfix, thereby dropping all connections and forcing SMTPAuth again. But this is rather undesirable, and unattractive. Are there other solutions to consider?With the default setting smtpd_delay_reject=yes each message is subject to the full set of smtpd restrictions.Can we add something similar to the "smtpd_client_restrictions" or "smtpd_recipient_restrictions", and adding a new rule-entry which would simply confirm that the "SMTPAuth LDAP 'user' used way back, is still accountStatus=enabled" ?The best approach for this is a policy service call before "permit_sasl_authenticated". The policy service can check wether the SASL username is still valid. Sadly Postfix does not have an access table keyed by the SASL login name. Perhaps we should bite the bullet, and add one, after defining a suitable encoding for any usernames that contain special or whitespace characters.
A workaround might be to force a mismatch with smtpd_sender_login_maps by removing the MAIL FROM --> Login-ID match in the table, no? But this only applies if reject_sender_login_mismatch could/should be used of course.
Regards Andreas
smime.p7s
Description: S/MIME Cryptographic Signature
