-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 6 Nov 2012, Christian Rößner wrote:
but I am looking for a mechanism that can reject Mail. Postfix can use reject_unverified_recipient to connect to LMTP and ask if a mail would successfully be enqueued and will return the status gotten from the LMTP server if not. Chances are high that the mechanism would work, too, if Dovecot would know about the sieve rule, while getting a connection on LMTP. Does Dovecot know all rules at this point or is sieve handled after the mail has already been accepted?
That is actually the point. As far as I know, all MTAs have already accepted the message, before they try to deliver it. If delivering fails, they queue them for retry.
I have no idea if your above idea would actually work, but having followed your questions on the postfix ml and your interests in using reject_unverified_recipient and its cache with lmtp, it would be very unwise to cache deliverability on the postfix side based on sieve results, since sieve is able to reject/bounce on any part of the message including message body contents and such.
yes I know what you mean. The problem is that a user can decide to "reject" not based on "from" leading in rejects to other mails coming in to the same user. Probably a problem.
Dunno about that discussion, did it included messages to multiple recipients, of which some reject and some accept the message? In SMTP you cannot individually fail a message after DATA phase.
The idea came up, as I work for a little ISP/ESP here. Sometimes I get calls, where I get asked if I could reject mails from "xyz". And with a robut good working mechanism, where people could reject on their on decisions would make things easier. So I thought about sieve as being a workable solution.
Another solution would be to write some kind of milter/policy-service with a web-interface, where people can reject mails directly on the postfix side. But this is a lot of work.
Look at CanIT / MIMEDefang.
Kind regards,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBUJjTwGoxLS8a3A9mAQKCuggAnAvnsShCbbEQGDgsR93aIg+Vc1w9HC7m NKWddvYIXRgTKC0qr6QM4tqkCIrtGVviylp+wFwyI+9ZvLx5t+3f8JFKHg0hO5MM Sbuu0ZmjCbm9STkNv2xvl72TBh5IWpByeKQt6fJQ5aT1f0Iqxo6i0+/Q0eoi5p82 HDgx27ASAtUqCHf+iPUg8G/FSndxxEcOvrSACn+hLfv71YU2iovgYTZazLt3u4pz hSWMQkpQyBwCxj75bz6y72sJxyMtd7XOMV5lGHumbSX6jg7WdI/cCScv14d2Uh5S D6yNya6+WB3AIGFg+NK9LuSz6IBq/eqIJivTGWvljOOIYsONnT8hbg== =/nYA -----END PGP SIGNATURE-----