Hi,
is there a sieve option that can reject a mail directly without creating a new mail and sending that out? I know about
reject "Reject message goes here";
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?
Kind regards
-Christian Rößner
-- [*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
On 11/6/12 8:59 AM, Christian Rößner wrote:
Hi,
is there a sieve option that can reject a mail directly without creating a new mail and sending that out? I know about
reject "Reject message goes here";
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?
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.
This could lead to very unpredictable rejects to unrelated messages, since the cache could obtain reject policies from sieve for a recipient based on a single rejected message containing the word '<insert spammy term here>'.
-- Tom
Hi,
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?
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.
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.
Kind regards
-Christian Rößner
-- [*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
-----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-----
Am 06.11.2012 10:09, schrieb Steffen Kaiser:
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.
it existed in horde 3 ingo, no idea for horde 5 stable
https://github.com/wrobel/horde-fw3/blob/master/ingo/scripts/ingo-postfix-po...
but if used you cant have ingo as sieve gui too at my knowledege
i suggested cloning this as on own horde module like "blocker" etc long time ago but i cant code it my own
anyway having such gui option for a reject policy server included in some webmail or postfixadmin , modoboa.org would be a really good idea
Best Regards MfG Robert Schetterer
-- [*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
On 11/6/2012 2:29 AM, Christian Rößner wrote:
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.
Use a web interface that requires auth. But I'd not use a milter/policy service--too complicated and unnecessary. Just use a regular access(5) table in db format. Simply write your script to append new addresses or domains to the table with a REJECT action. Then add to main.cf an appropriate restriction such as check_sender_access. Changes are picked up automatically each time a new smtpd is fired so no postmap command is required to make the change active.
-- Stan
Hi,
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.
Use a web interface that requires auth. But I'd not use a milter/policy service--too complicated and unnecessary. Just use a regular access(5) table in db format. Simply write your script to append new addresses or domains to the table with a REJECT action. Then add to main.cf an appropriate restriction such as check_sender_access. Changes are picked up automatically each time a new smtpd is fired so no postmap command is required to make the change active.
thanks to all of you. I think I have enough feedback and now I can decide what to do.
Kind regards
-Christian Rößner
-- [*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
May be, that solution of yout problem is mailfromd http://puszcza.gnu.org.ua/software/mailfromd/
Dne 6.11.2012 08:59, Christian Rößner napsal:
Hi,
is there a sieve option that can reject a mail directly without creating a new mail and sending that out? I know about
reject "Reject message goes here";
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?
Kind regards
-Christian Rößner
-- [*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
At 8AM +0100 on 6/11/12 you (Christian Rößner) wrote:
is there a sieve option that can reject a mail directly without creating a new mail and sending that out? I know about
reject "Reject message goes here";
but I am looking for a mechanism that can reject Mail.
You want 'ereject', RFC 5429, but Pigeonhole currently only implements it as a synonym for reject. I'm not sure if this is within-spec or not: this paragraph
The "ereject" action MUST NOT be available in environments that do
not support protocol-level rejection, e.g., an MUA, and MUST be
available in all other environments that support the "reject"
action.makes me think that perhaps it's not; in any case, Dovecot's implementation won't do what you want.
Ben
Op 11/6/2012 1:43 PM, Ben Morrow schreef:
You want 'ereject', RFC 5429, but Pigeonhole currently only implements it as a synonym for reject. I'm not sure if this is within-spec or not: this paragraph
The "ereject" action MUST NOT be available in environments that do not support protocol-level rejection, e.g., an MUA, and MUST be available in all other environments that support the "reject" action.makes me think that perhaps it's not; in any case, Dovecot's implementation won't do what you want.
That feature is under development, and such features aren't compiled unless people add `--with-unfinished-features' to their configure line. So, don't worry, Pigeonhole does not normally violate the specification in this regard.
Regards,
Stephan.
At 4PM +0100 on 6/11/12 you (Stephan Bosch) wrote:
Op 11/6/2012 1:43 PM, Ben Morrow schreef:
You want 'ereject', RFC 5429, but Pigeonhole currently only implements it as a synonym for reject. I'm not sure if this is within-spec or not: this paragraph
The "ereject" action MUST NOT be available in environments that do not support protocol-level rejection, e.g., an MUA, and MUST be available in all other environments that support the "reject" action.makes me think that perhaps it's not; in any case, Dovecot's implementation won't do what you want.
That feature is under development, and such features aren't compiled unless people add `--with-unfinished-features' to their configure line. So, don't worry, Pigeonhole does not normally violate the specification in this regard.
Oh, cool, I missed that on my quick look through the source.
Ben
participants (8)
-
Ben Morrow
-
Christian Rößner
-
Radek Novotný
-
Robert Schetterer
-
Stan Hoeppner
-
Steffen Kaiser
-
Stephan Bosch
-
Tom Hendrikx