-----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-----

Reply via email to