Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
ASPL: discarding a single recipient or a set of them from a multi-recipient message
463 views
Skip to first unread message
Francis Brosnan Blázquez
Sep 10, 2015, 7:20:44 AM9/10/15
to
Hello there,
First of all, congratulate all folks behind this remarkable, predictable
and reliable software that is postfix, which.......at the same time is
well documented (bonus). It is is difficult to find software with some
of these attributes, but postfix have them all.
--== CONTEXT OF THE PROBLEM ==--
Having said that, we are trying to implement a discard for a particular
recipient of a multi-recipient message (which seems to be something
recurrent). At this point, we are trying to discard based on the
destination domain and/or the local-part@ (without considering the
destination domain) by reporting a DISCARD code using delegation
protocol (with valvula [1]).
At the same time, we are using the following type of declarations at
master.cf, combined with FILTER command (delegation), to make a
particular sasl user to use a particular outgoing ip when accepted:
transport16 unix - - n - - smtp
-o smtp_bind_address=X.X.X.X
-o syslog_name=postfix16
--== WHAT FAILS ==--
After reviewing documentation about why discard applies to all
recipient, we have found that this is documented and expected behaviour:
http://www.postfix.org/access.5.html
Note: this action currently affects all recipients of the
message. To discard only one recipient without
discarding the entire message, use the transport(5) table to
direct mail to the discard(8) service.
After that, we have tried to implement suggested solution by declaring a
transport_maps = hash:/etc/postfix/transports
...where we declare destination domains we want to discard.
# with format
yahoogroups.com discard:
.yahoogroups.com discard:
# and the corresponding
>> postmap /etc/postfix/transports
However, we are finding two problems:
1) When a FILTER command is issued to a particular transport to use a
particular outbound IP (as shown in the example above, transport16), the
smtp(8) client created that delivers that message, entirely ignores any
declaration found for transport_maps = ..., so domains declared there,
aren't discarded.
2) Even though having previous point working, we haven't found any
possible solution to "discard:" (via transport) or DISCARD (via
delegation) based on the local-part@ in for a particular recipient in a
multi-recipient message.
--== QUESTIONS ==--
1) Is there a way do a DISCARD of a particular recipient in a
mult-recipient message and at the same time calling FILTER+trasnport16
to select a particular outgoing IP as we did?
2) Same question as 1) but from a different point of view, is there a
way to flag as "already handled/delivered" a particular recipient in a
message directly in the queue?
3) Are we wrong or the only solution is to go with a smtp-like content
filter that does the recipient removal?
Thanks for your time and patience,
Best Regards,
[1] http://www.aspl.es/valvula
--
Francis Brosnan Blázquez <francis...@aspl.es>
ASPL
91 134 14 22 - 91 134 14 45 - 91 116 07 57
AVISO LEGAL
Este mensaje se dirige exclusivamente a su destinatario. Los datos
incluidos en el presente correo son confidenciales y sometidos a secreto
profesional, se prohíbe divulgarlos, en virtud de las leyes vigentes. Si
usted no lo es y lo ha recibido por error o tiene conocimiento del mismo
por cualquier motivo, le rogamos que nos lo comunique por este medio y
proceda a destruirlo o borrarlo.
En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
diciembre, de Protección de Datos de Carácter Personal, le informamos de
que sus datos de carácter personal, recogidos de fuentes accesibles al
público o datos que usted nos ha facilitado previamente, proceden de
bases de datos propiedad de Advanced Software Production Line, S.L.
(ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y oposición dispuestos en la mencionada Ley
Orgánica, notificándolo por escrito a:
ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de
Henares (Madrid).
First of all, congratulate all folks behind this remarkable, predictable
and reliable software that is postfix, which.......at the same time is
well documented (bonus). It is is difficult to find software with some
of these attributes, but postfix have them all.
--== CONTEXT OF THE PROBLEM ==--
Having said that, we are trying to implement a discard for a particular
recipient of a multi-recipient message (which seems to be something
recurrent). At this point, we are trying to discard based on the
destination domain and/or the local-part@ (without considering the
destination domain) by reporting a DISCARD code using delegation
protocol (with valvula [1]).
At the same time, we are using the following type of declarations at
master.cf, combined with FILTER command (delegation), to make a
particular sasl user to use a particular outgoing ip when accepted:
transport16 unix - - n - - smtp
-o smtp_bind_address=X.X.X.X
-o syslog_name=postfix16
--== WHAT FAILS ==--
After reviewing documentation about why discard applies to all
recipient, we have found that this is documented and expected behaviour:
http://www.postfix.org/access.5.html
Note: this action currently affects all recipients of the
message. To discard only one recipient without
discarding the entire message, use the transport(5) table to
direct mail to the discard(8) service.
After that, we have tried to implement suggested solution by declaring a
transport_maps = hash:/etc/postfix/transports
...where we declare destination domains we want to discard.
# with format
yahoogroups.com discard:
.yahoogroups.com discard:
# and the corresponding
>> postmap /etc/postfix/transports
However, we are finding two problems:
1) When a FILTER command is issued to a particular transport to use a
particular outbound IP (as shown in the example above, transport16), the
smtp(8) client created that delivers that message, entirely ignores any
declaration found for transport_maps = ..., so domains declared there,
aren't discarded.
2) Even though having previous point working, we haven't found any
possible solution to "discard:" (via transport) or DISCARD (via
delegation) based on the local-part@ in for a particular recipient in a
multi-recipient message.
--== QUESTIONS ==--
1) Is there a way do a DISCARD of a particular recipient in a
mult-recipient message and at the same time calling FILTER+trasnport16
to select a particular outgoing IP as we did?
2) Same question as 1) but from a different point of view, is there a
way to flag as "already handled/delivered" a particular recipient in a
message directly in the queue?
3) Are we wrong or the only solution is to go with a smtp-like content
filter that does the recipient removal?
Thanks for your time and patience,
Best Regards,
[1] http://www.aspl.es/valvula
--
Francis Brosnan Blázquez <francis...@aspl.es>
ASPL
91 134 14 22 - 91 134 14 45 - 91 116 07 57
AVISO LEGAL
Este mensaje se dirige exclusivamente a su destinatario. Los datos
incluidos en el presente correo son confidenciales y sometidos a secreto
profesional, se prohíbe divulgarlos, en virtud de las leyes vigentes. Si
usted no lo es y lo ha recibido por error o tiene conocimiento del mismo
por cualquier motivo, le rogamos que nos lo comunique por este medio y
proceda a destruirlo o borrarlo.
En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
diciembre, de Protección de Datos de Carácter Personal, le informamos de
que sus datos de carácter personal, recogidos de fuentes accesibles al
público o datos que usted nos ha facilitado previamente, proceden de
bases de datos propiedad de Advanced Software Production Line, S.L.
(ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y oposición dispuestos en la mencionada Ley
Orgánica, notificándolo por escrito a:
ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de
Henares (Madrid).
Wietse Venema
Sep 10, 2015, 8:53:44 AM9/10/15
to
Francis Brosnan Bl?zquez:
recipient. To drop only the recipient, use transport_maps to send
the recipient to the discard(8) service.
/etc/postfix/main.cf:
transport_maps = hash:/etc/postfix/transport
/etc/postfix/transport:
us...@example.com discard:
After changing the file, do "postmap hash:/etc/postfix/transport".
To discard a recipient based on localpart, use a pcre table instead;
this requires no postmap command.
/etc/postfix/main.cf:
transport_maps = pcre:/etc/postfix/transport
/etc/postfix/transport:
# The ^ at the beginning is required to avoid false matches.
/^user@/ discard:
Of course this will have collateral damage; it discards mail for
recipients in unrelated domains.
Wietse
> At this point, we are trying to discard based on the destination
> domain and/or the local-part@ (without considering the destination
> domain) by reporting a DISCARD code using delegation protocol (with
> valvula [1]).
As documented, the DISCARD action discards the message, not the
> domain and/or the local-part@ (without considering the destination
> domain) by reporting a DISCARD code using delegation protocol (with
> valvula [1]).
recipient. To drop only the recipient, use transport_maps to send
the recipient to the discard(8) service.
/etc/postfix/main.cf:
transport_maps = hash:/etc/postfix/transport
/etc/postfix/transport:
us...@example.com discard:
After changing the file, do "postmap hash:/etc/postfix/transport".
To discard a recipient based on localpart, use a pcre table instead;
this requires no postmap command.
/etc/postfix/main.cf:
transport_maps = pcre:/etc/postfix/transport
/etc/postfix/transport:
# The ^ at the beginning is required to avoid false matches.
/^user@/ discard:
Of course this will have collateral damage; it discards mail for
recipients in unrelated domains.
Wietse
Francis Brosnan Blázquez
Sep 10, 2015, 11:39:27 AM9/10/15
to
Hi Wietse,
Thanks for your response. Assuming this information, it should discard
as indicated by transport_maps. However, we are not seeing this
behaviour.
This is the course of events:
1) Mail is accepted by postfix. After that, an indication is passed to
valvula on smtpd_data_restrictions:
smtpd_data_restrictions =
check_policy_service inet:127.0.0.1:3579
2) Then, valvula based on its configuration, reports FILTER transp2:
Sep 10 16:49:53 host valvulad[16853]: info: FILTER:
fra...@aspl.es -> w...@asplhost.com
(sasl_user=mailing-sasluser), port 3579, rcpt count=1, queue-id
11C68F762, from X.X.X.X, no-tls: transp2:
3) That causes postfix to use transp2 declared at master.cf,
Sep 10 16:49:53 host postfix/smtpd[15410]: 11C68F762: filter:
DATA from host[X.X.X.X]: <DATA>: Data command triggers FILTER
transp2:; from=<fra...@aspl.es> to=<w...@asplhost.com>
proto=ESMTP helo=<[192.168.0.132]>
...which activates smtp(8) transport with the following configuration at
master.cf:
transp2 unix - - n - - smtp
-o smtp_bind_address=X.X.X.X
-o smtp_helo_name=outboundname.asplhost.com
-o syslog_name=postfix2
4) But instead of discarding it, smtp(8) attempts to actually deliver it
without considering what's declared in transport_maps:
Sep 10 17:02:15 host postfix2/smtp[26624]: AC04CEA1A:
to=<w...@asplhost.com>, relay=mx1.asplhost.com[X.X.X.X]:25,
delay=74662, delays=74268/392/0.08/1.1, dsn=5.1.1,
status=bounced (host mx1.asplhost.com[X.X.X.X] said: 550 5.1.1
<w...@asplhost.com>: Recipient address rejected: User unknown in
virtual mailbox table (in reply to RCPT TO command))
NOTE: certainly it fails because the account does not exists,
but that's not the point: it should have been discarded
It is like smtp(8) is ignoring what's declared on transport_maps because
it already has an order to use the transport indicated by the FILTER
+transp2 (point 2). Is it right or it shouldn't happen?
If it is the intended behaviour, how can we configure a transport
(transp2) that instructs the particular IP to be used and, at the same
time, we can discard particular recipients in a multi-recipient message
using transport_maps?
Thanks for your time and support,
Best Regards,
PS: Here is the complete configuration file we are using:
http://www.aspl.es/postfix-main.cf.txt (ips and host
names masked)
http://www.aspl.es/postfix-master.cf.txt (ips and host
names masked)
At the same time, /etc/postfix/local-parts-spam-traps-accounts
has the following content:
/^web@/ discard:
Thanks for your response. Assuming this information, it should discard
as indicated by transport_maps. However, we are not seeing this
behaviour.
This is the course of events:
1) Mail is accepted by postfix. After that, an indication is passed to
valvula on smtpd_data_restrictions:
smtpd_data_restrictions =
check_policy_service inet:127.0.0.1:3579
2) Then, valvula based on its configuration, reports FILTER transp2:
Sep 10 16:49:53 host valvulad[16853]: info: FILTER:
fra...@aspl.es -> w...@asplhost.com
(sasl_user=mailing-sasluser), port 3579, rcpt count=1, queue-id
11C68F762, from X.X.X.X, no-tls: transp2:
3) That causes postfix to use transp2 declared at master.cf,
Sep 10 16:49:53 host postfix/smtpd[15410]: 11C68F762: filter:
DATA from host[X.X.X.X]: <DATA>: Data command triggers FILTER
transp2:; from=<fra...@aspl.es> to=<w...@asplhost.com>
proto=ESMTP helo=<[192.168.0.132]>
...which activates smtp(8) transport with the following configuration at
master.cf:
transp2 unix - - n - - smtp
-o smtp_bind_address=X.X.X.X
-o smtp_helo_name=outboundname.asplhost.com
-o syslog_name=postfix2
4) But instead of discarding it, smtp(8) attempts to actually deliver it
without considering what's declared in transport_maps:
Sep 10 17:02:15 host postfix2/smtp[26624]: AC04CEA1A:
to=<w...@asplhost.com>, relay=mx1.asplhost.com[X.X.X.X]:25,
delay=74662, delays=74268/392/0.08/1.1, dsn=5.1.1,
status=bounced (host mx1.asplhost.com[X.X.X.X] said: 550 5.1.1
<w...@asplhost.com>: Recipient address rejected: User unknown in
virtual mailbox table (in reply to RCPT TO command))
NOTE: certainly it fails because the account does not exists,
but that's not the point: it should have been discarded
It is like smtp(8) is ignoring what's declared on transport_maps because
it already has an order to use the transport indicated by the FILTER
+transp2 (point 2). Is it right or it shouldn't happen?
If it is the intended behaviour, how can we configure a transport
(transp2) that instructs the particular IP to be used and, at the same
time, we can discard particular recipients in a multi-recipient message
using transport_maps?
Thanks for your time and support,
Best Regards,
PS: Here is the complete configuration file we are using:
http://www.aspl.es/postfix-main.cf.txt (ips and host
names masked)
http://www.aspl.es/postfix-master.cf.txt (ips and host
names masked)
At the same time, /etc/postfix/local-parts-spam-traps-accounts
has the following content:
/^web@/ discard:
Wietse Venema
Sep 10, 2015, 12:01:13 PM9/10/15
to
Francis Brosnan Bl?zquez:
Wietse
> 2) Then, valvula based on its configuration, reports FILTER transp2:
>
> Sep 10 16:49:53 host valvulad[16853]: info: FILTER:
> fra...@aspl.es -> w...@asplhost.com
> (sasl_user=mailing-sasluser), port 3579, rcpt count=1, queue-id
> 11C68F762, from X.X.X.X, no-tls: transp2:
transport_maps takes effect ONLY AFTER the filter has processed the message.
>
> Sep 10 16:49:53 host valvulad[16853]: info: FILTER:
> fra...@aspl.es -> w...@asplhost.com
> (sasl_user=mailing-sasluser), port 3579, rcpt count=1, queue-id
> 11C68F762, from X.X.X.X, no-tls: transp2:
Wietse
Francis Brosnan Blázquez
Sep 10, 2015, 12:15:26 PM9/10/15
to
Hi Wietse,
> transport_maps takes effect ONLY AFTER the filter has processed the message.
Ok, so because transport_maps takes effect after filter, do you mean
transport_maps declarations will never take effect because at the time
filter finished, the delivery attempt was already made?
> Wietse
Best Regards,
> transport_maps takes effect ONLY AFTER the filter has processed the message.
transport_maps declarations will never take effect because at the time
filter finished, the delivery attempt was already made?
> Wietse
Best Regards,
Wietse Venema
Sep 10, 2015, 12:23:44 PM9/10/15
to
Francis Brosnan Bl?zquez:
This is how Postfix content filters work:
postfix1 -> filter -> postfix2
The filter takes precedence in postfix1; transport_maps takes effect
in postfix2.
Wietse
postfix1 -> filter -> postfix2
The filter takes precedence in postfix1; transport_maps takes effect
in postfix2.
Wietse
Francis Brosnan Blázquez
Sep 10, 2015, 1:02:36 PM9/10/15
to
Hi Wietse,
Thanks for your response,
> This is how Postfix content filters work:
>
> postfix1 -> filter -> postfix2
>
> The filter takes precedence in postfix1;
Just to clarify we are talking about the same thing, "filter" is not a
"content filter" taking the mail from postfix and re-injecting it into
postfix, but valvula reporting "FILTER transp2:", as described at [1],
using delegation protocol ([2]),
> transport_maps takes effect in postfix2.
I'm confused about this statement because it is not what's happening
right now and I have shown an example that demonstrates it :-?
If I update valvula's configuration to report DUNNO, and hence,
disabling the activation of "FILTER transp2:", then configurations
declared at transport_maps are honoured,
Sep 10 18:53:06 host postfix/smtpd[17286]: connect from tarsonis.asplhost.com[X.X.X.X]
Sep 10 18:53:07 host postfix/smtpd[17286]: 156A3FB18: client=tarsonis.asplhost.com[X.X.X.X], sasl_method=PLAIN, sasl_username=mailing-sasluser
Sep 10 18:53:08 host valvulad[16853]: info: DUNNO: fra...@aspl.es -> w...@asplhost.com (sasl_user=mailing-sasluser), port 3579, rcpt count=1, queue-id 156A3FB18, from X.X.X.X, no-tls
Sep 10 18:53:08 host postfix/discard[17530]: 156A3FB18: to=<w...@asplhost.com>, relay=none, delay=1, delays=1/0/0/0, dsn=2.0.0, status=sent (asplhost.com)
Sep 10 18:53:09 host postfix/smtpd[17286]: disconnect from tarsonis.asplhost.com[X.X.X.X]
But if I make valvula to report "FILTER transp2:", then postfix2, in the
diagram "postfix1 -> filter -> postfix2" completely ignores
transport_maps:
Sep 10 18:56:59 host postfix/smtpd[25423]: connect from tarsonis.asplhosting.com[X.X.X.X]
Sep 10 18:56:59 host postfix/smtpd[25423]: A1A0AEB03: client=tarsonis.asplhost.com[X.X.X.X], sasl_method=PLAIN, sasl_username=mailing-sasluser
Sep 10 18:56:59 host valvulad[16853]: info: FILTER: fra...@aspl.es -> w...@asplhost.com (sasl_user=mailing-sasluser), port 3579, rcpt count=1, queue-id A1A0AEB03, from X.X.X.X, no-tls: transp2:
Sep 10 18:56:59 host postfix/smtpd[25423]: A1A0AEB03: filter: DATA from tarsonis.asplhost.com[X.X.X.X]: <DATA>: Data command triggers FILTER transp2:; from=<fra...@aspl.es> to=<w...@asplhost.com> proto=ESMTP helo=<[192.168.0.132]>
Sep 10 18:57:00 host postfix/smtpd[25423]: disconnect from tarsonis.asplhost.com[X.X.X.X]
Sep 10 18:57:00 host postfix2/smtp[23095]: A1A0AEB03: to=<w...@asplhost.com>, relay=mx1.aspl.es[89.140.237.70]:25, delay=1.3, delays=0.07/0/0.17/1, dsn=5.1.1, status=bounced (host mx1.aspl.es[89.140.237.70] said: 550 5.1.1 <w...@asplhost.com>: Recipient address rejected: User unknown in virtual mailbox table (in reply to RCPT TO command))
What I'm missing? Thanks for your patience and time,
Best Regards,
> Wietse
[1] http://www.postfix.org/access.5.html
[2] http://www.postfix.org/SMTPD_POLICY_README.html
Thanks for your response,
> This is how Postfix content filters work:
>
> postfix1 -> filter -> postfix2
>
> The filter takes precedence in postfix1;
"content filter" taking the mail from postfix and re-injecting it into
postfix, but valvula reporting "FILTER transp2:", as described at [1],
using delegation protocol ([2]),
> transport_maps takes effect in postfix2.
right now and I have shown an example that demonstrates it :-?
If I update valvula's configuration to report DUNNO, and hence,
disabling the activation of "FILTER transp2:", then configurations
declared at transport_maps are honoured,
Sep 10 18:53:06 host postfix/smtpd[17286]: connect from tarsonis.asplhost.com[X.X.X.X]
Sep 10 18:53:07 host postfix/smtpd[17286]: 156A3FB18: client=tarsonis.asplhost.com[X.X.X.X], sasl_method=PLAIN, sasl_username=mailing-sasluser
Sep 10 18:53:08 host valvulad[16853]: info: DUNNO: fra...@aspl.es -> w...@asplhost.com (sasl_user=mailing-sasluser), port 3579, rcpt count=1, queue-id 156A3FB18, from X.X.X.X, no-tls
Sep 10 18:53:08 host postfix/discard[17530]: 156A3FB18: to=<w...@asplhost.com>, relay=none, delay=1, delays=1/0/0/0, dsn=2.0.0, status=sent (asplhost.com)
Sep 10 18:53:09 host postfix/smtpd[17286]: disconnect from tarsonis.asplhost.com[X.X.X.X]
But if I make valvula to report "FILTER transp2:", then postfix2, in the
diagram "postfix1 -> filter -> postfix2" completely ignores
transport_maps:
Sep 10 18:56:59 host postfix/smtpd[25423]: connect from tarsonis.asplhosting.com[X.X.X.X]
Sep 10 18:56:59 host postfix/smtpd[25423]: A1A0AEB03: client=tarsonis.asplhost.com[X.X.X.X], sasl_method=PLAIN, sasl_username=mailing-sasluser
Sep 10 18:56:59 host valvulad[16853]: info: FILTER: fra...@aspl.es -> w...@asplhost.com (sasl_user=mailing-sasluser), port 3579, rcpt count=1, queue-id A1A0AEB03, from X.X.X.X, no-tls: transp2:
Sep 10 18:56:59 host postfix/smtpd[25423]: A1A0AEB03: filter: DATA from tarsonis.asplhost.com[X.X.X.X]: <DATA>: Data command triggers FILTER transp2:; from=<fra...@aspl.es> to=<w...@asplhost.com> proto=ESMTP helo=<[192.168.0.132]>
Sep 10 18:57:00 host postfix/smtpd[25423]: disconnect from tarsonis.asplhost.com[X.X.X.X]
Sep 10 18:57:00 host postfix2/smtp[23095]: A1A0AEB03: to=<w...@asplhost.com>, relay=mx1.aspl.es[89.140.237.70]:25, delay=1.3, delays=0.07/0/0.17/1, dsn=5.1.1, status=bounced (host mx1.aspl.es[89.140.237.70] said: 550 5.1.1 <w...@asplhost.com>: Recipient address rejected: User unknown in virtual mailbox table (in reply to RCPT TO command))
What I'm missing? Thanks for your patience and time,
Best Regards,
> Wietse
[1] http://www.postfix.org/access.5.html
[2] http://www.postfix.org/SMTPD_POLICY_README.html
Viktor Dukhovni
Sep 10, 2015, 1:13:18 PM9/10/15
to
On Thu, Sep 10, 2015 at 07:01:59PM +0200, Francis Brosnan Blázquez wrote:
> > This is how Postfix content filters work:
> >
> > postfix1 -> filter -> postfix2
> >
> > The filter takes precedence in postfix1;
>
> Just to clarify we are talking about the same thing, "filter" is not a
> "content filter" taking the mail from postfix and re-injecting it into
> postfix, but valvula reporting "FILTER transp2:", as described at [1],
> using delegation protocol ([2]),
If your policy service says "FILTER ..." it is setting a content_filter
> > This is how Postfix content filters work:
> >
> > postfix1 -> filter -> postfix2
> >
> > The filter takes precedence in postfix1;
>
> Just to clarify we are talking about the same thing, "filter" is not a
> "content filter" taking the mail from postfix and re-injecting it into
> postfix, but valvula reporting "FILTER transp2:", as described at [1],
> using delegation protocol ([2]),
that preempts transport table routing for *all* recipients.
> I'm confused about this statement because it is not what's happening
> right now and I have shown an example that demonstrates it :-?
> But if I make valvula to report "FILTER transp2:", then postfix2, in the
> diagram "postfix1 -> filter -> postfix2" completely ignores
> transport_maps:
back into Postfix (bypassing the policy service with its FILTER
replies).
--
Viktor.
Francis Brosnan Blázquez
Sep 10, 2015, 1:53:03 PM9/10/15
to
Hi Victor,
Thanks for your response,
> If your policy service says "FILTER ..." it is setting a
> content_filter that preempts transport table routing for *all*
> recipients.
Ok, thanks for clarifying this. It was one of questions we did but
wasn't resolved (from my previous mail):
It is like smtp(8) is ignoring what's declared on transport_maps
because it already has an order to use the transport indicated
by the FILTER +transp2 (point 2). Is it right or it shouldn't
happen?
> > But if I make valvula to report "FILTER transp2:", then postfix2, in
> the> diagram "postfix1 -> filter -> postfix2" completely ignores
> > transport_maps:
>
> Exactly as it should, it is up to "transp2" to re-inject the mail
> back into Postfix (bypassing the policy service with its FILTER
> replies).
Ok, so Victor, going back to the initial question, assuming that:
1) We need that "FILTER transp2:", through the delegation protocol, to
setup different outgoing IP (it seems there's no other way to do this),
2) And we need some way to discard a single recipient (by destination
domain or destination local-part@) in a multi-recipient message,
Is there any way to do it without having to write an external
content-filter (as described in [1])?
Can it be done reusing postfix components?
...or there's no other option :-( ?
Thanks for your time,
Best Regards,
[1] http://www.postfix.org/FILTER_README.html
Thanks for your response,
> If your policy service says "FILTER ..." it is setting a
> content_filter that preempts transport table routing for *all*
> recipients.
wasn't resolved (from my previous mail):
It is like smtp(8) is ignoring what's declared on transport_maps
because it already has an order to use the transport indicated
by the FILTER +transp2 (point 2). Is it right or it shouldn't
happen?
> > I'm confused about this statement because it is not what's happening
> > right now and I have shown an example that demonstrates it :-?
>
> Yes, you're confused. No, you don't have a counter-example.
:-)
> > right now and I have shown an example that demonstrates it :-?
>
> Yes, you're confused. No, you don't have a counter-example.
> > But if I make valvula to report "FILTER transp2:", then postfix2, in
> the> diagram "postfix1 -> filter -> postfix2" completely ignores
> > transport_maps:
>
> Exactly as it should, it is up to "transp2" to re-inject the mail
> back into Postfix (bypassing the policy service with its FILTER
> replies).
1) We need that "FILTER transp2:", through the delegation protocol, to
setup different outgoing IP (it seems there's no other way to do this),
2) And we need some way to discard a single recipient (by destination
domain or destination local-part@) in a multi-recipient message,
Is there any way to do it without having to write an external
content-filter (as described in [1])?
Can it be done reusing postfix components?
...or there's no other option :-( ?
Thanks for your time,
Best Regards,
[1] http://www.postfix.org/FILTER_README.html
Viktor Dukhovni
Sep 10, 2015, 2:11:45 PM9/10/15
to
On Thu, Sep 10, 2015 at 07:52:37PM +0200, Francis Brosnan Blázquez wrote:
> Ok, so Victor, going back to the initial question, assuming that:
>
> 1) We need that "FILTER transp2:", through the delegation protocol, to
> setup different outgoing IP (it seems there's no other way to do this),
By sender:
> Ok, so Victor, going back to the initial question, assuming that:
>
> 1) We need that "FILTER transp2:", through the delegation protocol, to
> setup different outgoing IP (it seems there's no other way to do this),
http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps
Outgoing IP by recipient domain is just normal transport lookup
(with the IP address part of the master.cf transport definition).
Content filters are NOT how you should do mail routing.
> 2) And we need some way to discard a single recipient (by destination
> domain or destination local-part@) in a multi-recipient message,
> Is there any way to do it without having to write an external
> content-filter (as described in [1])?
"discard" transport works.
Postfix is not a one-stop-shopping solution for a snow-shoe spam
MTA. Removing pesky recipients like me who'll report the sender
to RBL maintainers and abuse departments needs to happen in the
upstream lists, not in the MTA. Turn-away customers with harvested
lists, or you'll find your outbound IPs on RBLs.
--
Viktor.
Francis Brosnan Blázquez
Sep 10, 2015, 4:08:07 PM9/10/15
to
Hi Victor,
Thanks for your response. At least, now we know the path we don't have
to follow,
> > 1) We need that "FILTER transp2:", through the delegation protocol, to
> > setup different outgoing IP (it seems there's no other way to do this),
>
> By sender:
>
> http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps
>
> Outgoing IP by recipient domain is just normal transport lookup
> (with the IP address part of the master.cf transport definition).
Yes, but this doesn't work if you need to adjust outgoing IP based on
the sasl user (published solutions insist on using FILTER :-( [1])
> Content filters are NOT how you should do mail routing.
Ok, I'll review this,
> > 2) And we need some way to discard a single recipient (by destination
> > domain or destination local-part@) in a multi-recipient message,
>
> Resolve that recipient to the "discard" transport.
>
> > Is there any way to do it without having to write an external
> > content-filter (as described in [1])?
>
> If you don't abuse content_filters for routing, then using the
> "discard" transport works.
Ok.
> Postfix is not a one-stop-shopping solution for a snow-shoe spam
> MTA. Removing pesky recipients like me who'll report the sender
> to RBL maintainers and abuse departments needs to happen in the
> upstream lists, not in the MTA. Turn-away customers with harvested
> lists, or you'll find your outbound IPs on RBLs.
:-) Hehe...I'd really like to (turn away those customers), but daily
life reality is far from there...
Anyway, certainly, that "FILTER" for transport selection we are doing is
very disruptive (according to postfix way of doing things). I'll take me
time to review this,
Thanks for taking your time,
Best Regards,
[1] http://comments.gmane.org/gmane.mail.postfix.user/250046
--
Francis Brosnan Blázquez <fra...@aspl.es>
las oportunas relaciones comerciales o promocionales con usted o la
entidad que usted representa. No obstante, usted puede ejercitar sus
Thanks for your response. At least, now we know the path we don't have
to follow,
> > 1) We need that "FILTER transp2:", through the delegation protocol, to
> > setup different outgoing IP (it seems there's no other way to do this),
>
> By sender:
>
> http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps
>
> Outgoing IP by recipient domain is just normal transport lookup
> (with the IP address part of the master.cf transport definition).
the sasl user (published solutions insist on using FILTER :-( [1])
> Content filters are NOT how you should do mail routing.
> > 2) And we need some way to discard a single recipient (by destination
> > domain or destination local-part@) in a multi-recipient message,
>
> Resolve that recipient to the "discard" transport.
>
> > Is there any way to do it without having to write an external
> > content-filter (as described in [1])?
>
> If you don't abuse content_filters for routing, then using the
> "discard" transport works.
> Postfix is not a one-stop-shopping solution for a snow-shoe spam
> MTA. Removing pesky recipients like me who'll report the sender
> to RBL maintainers and abuse departments needs to happen in the
> upstream lists, not in the MTA. Turn-away customers with harvested
> lists, or you'll find your outbound IPs on RBLs.
life reality is far from there...
Anyway, certainly, that "FILTER" for transport selection we are doing is
very disruptive (according to postfix way of doing things). I'll take me
time to review this,
Thanks for taking your time,
Best Regards,
[1] http://comments.gmane.org/gmane.mail.postfix.user/250046
--
Francis Brosnan Blázquez <fra...@aspl.es>
ASPL
91 134 14 22 - 91 134 14 45 - 91 116 07 57
AVISO LEGAL
91 134 14 22 - 91 134 14 45 - 91 116 07 57
AVISO LEGAL
En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
diciembre, de Protección de Datos de Carácter Personal, le informamos de
que sus datos de carácter personal, recogidos de fuentes accesibles al
público o datos que usted nos ha facilitado previamente, proceden de
bases de datos propiedad de Advanced Software Production Line, S.L.
(ASPL).
ASPL garantiza que los datos serán tratados con la finalidad de mantener
diciembre, de Protección de Datos de Carácter Personal, le informamos de
que sus datos de carácter personal, recogidos de fuentes accesibles al
público o datos que usted nos ha facilitado previamente, proceden de
bases de datos propiedad de Advanced Software Production Line, S.L.
(ASPL).
las oportunas relaciones comerciales o promocionales con usted o la
entidad que usted representa. No obstante, usted puede ejercitar sus
Viktor Dukhovni
Sep 10, 2015, 4:24:09 PM9/10/15
to
On Thu, Sep 10, 2015 at 10:06:24PM +0200, Francis Brosnan Blázquez wrote:
> > > 1) We need that "FILTER transp2:", through the delegation protocol, to
> > > setup different outgoing IP (it seems there's no other way to do this),
> >
> > By sender:
> >
> > http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps
> >
> > Outgoing IP by recipient domain is just normal transport lookup
> > (with the IP address part of the master.cf transport definition).
>
> Yes, but this doesn't work if you need to adjust outgoing IP based on
> the sasl user (published solutions insist on using FILTER :-( [1])
Then perhaps we should provide a way of doing the same thing by
> > > 1) We need that "FILTER transp2:", through the delegation protocol, to
> > > setup different outgoing IP (it seems there's no other way to do this),
> >
> > By sender:
> >
> > http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps
> >
> > Outgoing IP by recipient domain is just normal transport lookup
> > (with the IP address part of the master.cf transport definition).
>
> Yes, but this doesn't work if you need to adjust outgoing IP based on
> the sasl user (published solutions insist on using FILTER :-( [1])
SASL login. Both the envelope address and the SASL login name are
really features of the sender. The original purpose of the feature
(in the form of a sender dependent relay host) was to allow users
to relay mail through the right email provider that hosts the
mailbox for the sender address, and might have DKIM, SPF, ...
I don't think that we're going out of our way to facilitate snow-show
bulk-email (possibly legitimate, and just dealing with real obstacles,
or at times trying to flying under the radar with less legitimate
content).
So there's a limit to how much effort in that direction is likely
in the mainstream Postfix distribution.
What are the legitimate use-cases for transport for SASL id?
> > Postfix is not a one-stop-shopping solution for a snow-shoe spam
> > MTA. Removing pesky recipients like me who'll report the sender
> > to RBL maintainers and abuse departments needs to happen in the
> > upstream lists, not in the MTA. Turn-away customers with harvested
> > lists, or you'll find your outbound IPs on RBLs.
>
> :-) Hehe...I'd really like to (turn away those customers), but daily
> life reality is far from there...
>
> Anyway, certainly, that "FILTER" for transport selection we are doing is
> very disruptive (according to postfix way of doing things). I'll take me
> time to review this,
>
Well, that works provided you don't also try to do any interesting
per-recipient routing (e.g. routing to discard(8)).
There isn't at present a "DEFAULT ..." access(5) directive that
instead of "FILTER", which preempts routing, sets the default
transport. This would have to write a new record into the queue-file
that the queue-manager would then convey to trivial-rewrite(8) in
the "resolve" protocol request (which would need to change), so
that trivial-rewrite would return the per-message default transport.
Can't estimate the likelihood of this becoming an official feature.
--
Viktor.
Francis Brosnan Blázquez
Sep 11, 2015, 6:59:10 AM9/11/15
to
Hi Viktor,
> > Yes, but this doesn't work if you need to adjust outgoing IP based on
> > the sasl user (published solutions insist on using FILTER :-( [1])
>
> Then perhaps we should provide a way of doing the same thing by
> SASL login. Both the envelope address and the SASL login name are
> really features of the sender. The original purpose of the feature
> (in the form of a sender dependent relay host) was to allow users
> to relay mail through the right email provider that hosts the
> mailbox for the sender address, and might have DKIM, SPF, ...
>
> I don't think that we're going out of our way to facilitate snow-show
> bulk-email (possibly legitimate, and just dealing with real obstacles,
> or at times trying to flying under the radar with less legitimate
> content).
>
> So there's a limit to how much effort in that direction is likely
> in the mainstream Postfix distribution.
>
> What are the legitimate use-cases for transport for SASL id?
Ok, before explaining the use case, I would like to recall why this
thread was started: to have the possibility to selectively discard
recipients in a multi-recipient message.
However, after sharing with you both the case, and reviewing the issue,
we are starting to consider the problem not as such, but as a limitation
which is somehow caused/activated by the way the email agent is sending
content and, more over, and possibly, more important, sending content to
accounts that will cause us problems (RBLs), which is something we
cannot accept (obviously).
Having said that, the use case follows.
What we have now is a good balance where users are grouped into
different outgoing IP, so we can reduce the impact of a compromised
accounts ([1]), and at the same time we don't have to deal with
different combinations of sender+sasl-user ([1]) so we do the routing
using the SASL identifer,
Even though mail sending is controlled by quotas and we also implement
sender login mismatch (sasl identifier must much sender account),
there's a set of "users" that have exceptions (for the complexity and
commercial reasons), but not spammers (unless they got compromised, of
course).
Given all this, the big likelihood this can be used for bad things(tm)
and the fact that, even implemented, we will not be able to take
advantage of it in the short term, the reasonable conclusion for us is
that we have to work out the problem by other means (which may include
users' reeducation :-)
> > > Postfix is not a one-stop-shopping solution for a snow-shoe spam
> > > MTA. Removing pesky recipients like me who'll report the sender
> > > to RBL maintainers and abuse departments needs to happen in the
> > > upstream lists, not in the MTA. Turn-away customers with harvested
> > > lists, or you'll find your outbound IPs on RBLs.
> >
> > :-) Hehe...I'd really like to (turn away those customers), but daily
> > life reality is far from there...
> >
> > Anyway, certainly, that "FILTER" for transport selection we are doing is
> > very disruptive (according to postfix way of doing things). I'll take me
> > time to review this,
> >
> > [1] http://comments.gmane.org/gmane.mail.postfix.user/250046
>
> Well, that works provided you don't also try to do any interesting
> per-recipient routing (e.g. routing to discard(8)).
>
> There isn't at present a "DEFAULT ..." access(5) directive that
> instead of "FILTER", which preempts routing, sets the default
> transport. This would have to write a new record into the queue-file
> that the queue-manager would then convey to trivial-rewrite(8) in
> the "resolve" protocol request (which would need to change), so
> that trivial-rewrite would return the per-message default transport.
Ok,
> Can't estimate the likelihood of this becoming an official feature.
Looks reasonable to me,
Thanks for all clarifications and comments Viktor,
Best Regards,
[1] The amount of users that care about its box, do not use wifi
connections that shouldn't be used, do not install unrecommended
software (thus compromising his/her equipment) and do not configure
fancy combinations of my-yahoo-account+sasl_user_of_my_isp is function
that nearly approximates to 0
> > Yes, but this doesn't work if you need to adjust outgoing IP based on
> > the sasl user (published solutions insist on using FILTER :-( [1])
>
> Then perhaps we should provide a way of doing the same thing by
> SASL login. Both the envelope address and the SASL login name are
> really features of the sender. The original purpose of the feature
> (in the form of a sender dependent relay host) was to allow users
> to relay mail through the right email provider that hosts the
> mailbox for the sender address, and might have DKIM, SPF, ...
>
> I don't think that we're going out of our way to facilitate snow-show
> bulk-email (possibly legitimate, and just dealing with real obstacles,
> or at times trying to flying under the radar with less legitimate
> content).
>
> So there's a limit to how much effort in that direction is likely
> in the mainstream Postfix distribution.
>
> What are the legitimate use-cases for transport for SASL id?
thread was started: to have the possibility to selectively discard
recipients in a multi-recipient message.
However, after sharing with you both the case, and reviewing the issue,
we are starting to consider the problem not as such, but as a limitation
which is somehow caused/activated by the way the email agent is sending
content and, more over, and possibly, more important, sending content to
accounts that will cause us problems (RBLs), which is something we
cannot accept (obviously).
Having said that, the use case follows.
What we have now is a good balance where users are grouped into
different outgoing IP, so we can reduce the impact of a compromised
accounts ([1]), and at the same time we don't have to deal with
different combinations of sender+sasl-user ([1]) so we do the routing
using the SASL identifer,
Even though mail sending is controlled by quotas and we also implement
sender login mismatch (sasl identifier must much sender account),
there's a set of "users" that have exceptions (for the complexity and
commercial reasons), but not spammers (unless they got compromised, of
course).
Given all this, the big likelihood this can be used for bad things(tm)
and the fact that, even implemented, we will not be able to take
advantage of it in the short term, the reasonable conclusion for us is
that we have to work out the problem by other means (which may include
users' reeducation :-)
> > > Postfix is not a one-stop-shopping solution for a snow-shoe spam
> > > MTA. Removing pesky recipients like me who'll report the sender
> > > to RBL maintainers and abuse departments needs to happen in the
> > > upstream lists, not in the MTA. Turn-away customers with harvested
> > > lists, or you'll find your outbound IPs on RBLs.
> >
> > :-) Hehe...I'd really like to (turn away those customers), but daily
> > life reality is far from there...
> >
> > Anyway, certainly, that "FILTER" for transport selection we are doing is
> > very disruptive (according to postfix way of doing things). I'll take me
> > time to review this,
> >
> > [1] http://comments.gmane.org/gmane.mail.postfix.user/250046
>
> Well, that works provided you don't also try to do any interesting
> per-recipient routing (e.g. routing to discard(8)).
>
> There isn't at present a "DEFAULT ..." access(5) directive that
> instead of "FILTER", which preempts routing, sets the default
> transport. This would have to write a new record into the queue-file
> that the queue-manager would then convey to trivial-rewrite(8) in
> the "resolve" protocol request (which would need to change), so
> that trivial-rewrite would return the per-message default transport.
> Can't estimate the likelihood of this becoming an official feature.
Thanks for all clarifications and comments Viktor,
Best Regards,
[1] The amount of users that care about its box, do not use wifi
connections that shouldn't be used, do not install unrecommended
software (thus compromising his/her equipment) and do not configure
fancy combinations of my-yahoo-account+sasl_user_of_my_isp is function
that nearly approximates to 0
Wietse Venema
Sep 11, 2015, 9:03:01 AM9/11/15
to
You could use virtual_alias_maps to rewrite the envelope recipient
to a bit-bucket address (virtual aliases take effect unless you
specify alias expansion with receive_override_options).
Either way, the sender-dependent delivery agent would need to be
able to deliver the bit-bucket address to a destination that
always accepts it.
Wietse
0 new messages