Discussion:
REJECT_ALL_RECIPIENTS
(too old to reply)
Noel Jones
2012-02-24 03:57:36 UTC
Permalink
Please refer to the recent incredibly long and wandering thread on
postfix-users with subject: Need to clarfiy how to implement
spamtrap address checking & discard with before-queue filtering.

Is there any interest in a REJECT_ALL/REJECT_DAMMIT access action?

My thought is a flag similar to DEFER_IF_PERMIT that issues a 5xx at
DATA.

Something like this in access(5)
REJECT_ALL_RECIPIENTS optional text...
Reject all recipients of a single- or multi-recipient
message. Reply with "$access_map_reject_code optional
text" when optional text is specified, otherwise reply
with a generic error response message.


-- Noel Jones
Wietse Venema
2012-02-24 11:33:09 UTC
Permalink
Post by Noel Jones
Please refer to the recent incredibly long and wandering thread on
postfix-users with subject: Need to clarfiy how to implement
spamtrap address checking & discard with before-queue filtering.
Is there any interest in a REJECT_ALL/REJECT_DAMMIT access action?
I thought the poster wanted to dicard, not reject?

Wietse
Post by Noel Jones
My thought is a flag similar to DEFER_IF_PERMIT that issues a 5xx at
DATA.
Something like this in access(5)
REJECT_ALL_RECIPIENTS optional text...
Reject all recipients of a single- or multi-recipient
message. Reply with "$access_map_reject_code optional
text" when optional text is specified, otherwise reply
with a generic error response message.
-- Noel Jones
Noel Jones
2012-02-24 13:35:58 UTC
Permalink
Post by Wietse Venema
Post by Noel Jones
Please refer to the recent incredibly long and wandering thread on
postfix-users with subject: Need to clarfiy how to implement
spamtrap address checking & discard with before-queue filtering.
Is there any interest in a REJECT_ALL/REJECT_DAMMIT access action?
I thought the poster wanted to dicard, not reject?
Wietse
Part of the discussion was that there is no convenient way to reject
all recipients of a message based on a single blacklist recipient,
which would have eliminated the need for DISCARD -- a message-level
action -- in this case.

The alternative is to PREPEND a "X-RejectMe: Yes" header, then
REJECT that header in header_checks, which I suppose isn't all that bad.



-- Noel Jones
Post by Wietse Venema
Post by Noel Jones
My thought is a flag similar to DEFER_IF_PERMIT that issues a 5xx at
DATA.
Something like this in access(5)
REJECT_ALL_RECIPIENTS optional text...
Reject all recipients of a single- or multi-recipient
message. Reply with "$access_map_reject_code optional
text" when optional text is specified, otherwise reply
with a generic error response message.
-- Noel Jones
Wietse Venema
2012-02-24 14:39:21 UTC
Permalink
Post by Noel Jones
Post by Wietse Venema
Post by Noel Jones
Please refer to the recent incredibly long and wandering thread on
postfix-users with subject: Need to clarfiy how to implement
spamtrap address checking & discard with before-queue filtering.
Is there any interest in a REJECT_ALL/REJECT_DAMMIT access action?
I thought the poster wanted to dicard, not reject?
Wietse
Part of the discussion was that there is no convenient way to reject
all recipients of a message based on a single blacklist recipient,
...

Replying with "521", which results in automatic disconnect since
Postfix 2.6, would also prevent the mail from coming in. But no-one
would come up with that unless they are a Postfix veteran.
Post by Noel Jones
The alternative is to PREPEND a "X-RejectMe: Yes" header, then
REJECT that header in header_checks, which I suppose isn't all that bad.
He could not use DISCARD in the before-filter SMTP server, so we
offer a PREPEND solution instead. Exceptions and workarounds like
this make Postfix difficult to use: PREPEND works with before-filter
SMTP daemons, but DISCARD/REDIRECT/FILTER/HOLD not, SMTP-level
actions can differ per recipient, header/body_checks not.

Some limitations are fundamental; for example there is no robust
way to propagate FILTER, REDIRECT, HOLD, etc. through an SMTP-based
filter (passing them along in custom mail headers is not robust).

Some features require a great deal of implementation effort; for
example to implement DISCARD in a before-filter SMTP server one
would have to change the before-filter SMTP server's plumbing
on-the-fly to divert the remainder of a MAIL transaction to a null
output driver. This requires a major restructuring of the way that
the SMTP server writes a MAIL transaction to queue file, cleanup
daemon or proxy filter with proper constructors and destructors
that clean up when a transaction is canceled.

Wietse
Noel Jones
2012-02-24 14:50:51 UTC
Permalink
Post by Wietse Venema
Replying with "521", which results in automatic disconnect since
Postfix 2.6, would also prevent the mail from coming in. But no-one
would come up with that unless they are a Postfix veteran.
Doh! I should have thought of that.
Post by Wietse Venema
Exceptions and workarounds like
...
Post by Wietse Venema
Some limitations are fundamental;
Thanks for the discussion. Request withdrawn.



-- Noel Jones

Loading...