Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Pick the transport based on the destination host, not domain?
106 views
Skip to first unread message
Darren Pilgrim
Nov 22, 2014, 3:21:24 PM11/22/14
to
I've run into a problem with a hosting service's IPv6 connectivity.
Their IPv6 broken such that they get odd transient failures. Normally
not a problem, but their anti-spam appliance or whatever they're using
in front of their mail servers hard-bounces on those failures instead of
following the established-since-forever practice of soft-bouncing on
such issues.
Originally I had only one domain using this hoster, so for that one
domain I simply added a transport map that points the domain at the an
extra smtp transport that has -o inet_protocols=ipv4.
But now I have a second such doamin, and I'd like to head-off a
maintenance problem. All such domains use the same set of MXes, so it's
an obvious pattern to switch transports if the next hop is one of the
offending MXes.
Can Postfix even do this? A read through the relevant docs indicates
those transport lookups are based solely on recipient domain.
If it can't, is there something out there that can do this using the
socketmap interface? If not, I'll write one.
Their IPv6 broken such that they get odd transient failures. Normally
not a problem, but their anti-spam appliance or whatever they're using
in front of their mail servers hard-bounces on those failures instead of
following the established-since-forever practice of soft-bouncing on
such issues.
Originally I had only one domain using this hoster, so for that one
domain I simply added a transport map that points the domain at the an
extra smtp transport that has -o inet_protocols=ipv4.
But now I have a second such doamin, and I'd like to head-off a
maintenance problem. All such domains use the same set of MXes, so it's
an obvious pattern to switch transports if the next hop is one of the
offending MXes.
Can Postfix even do this? A read through the relevant docs indicates
those transport lookups are based solely on recipient domain.
If it can't, is there something out there that can do this using the
socketmap interface? If not, I'll write one.
A. Schulze
Nov 22, 2014, 4:13:04 PM11/22/14
to
Darren Pilgrim:
> But now I have a second such doamin, and I'd like to head-off a
> maintenance problem. All such domains use the same set of MXes, so
> it's an obvious pattern to switch transports if the next hop is one
> of the offending MXes.
- modify your local dns resolver to strip the AAAA part in it's answer
for the hosts in question
- modify your local firewall to *reject* outbound connections to the
IPv6 address in question
both are not perfect any may have unwanted side effects.
Andreas
Darren Pilgrim
Nov 22, 2014, 4:34:17 PM11/22/14
to
On 11/22/2014 1:12 PM, A. Schulze wrote:
> Darren Pilgrim:
>
>> But now I have a second such doamin, and I'd like to head-off a
>> maintenance problem. All such domains use the same set of MXes, so
>> it's an obvious pattern to switch transports if the next hop is one
>> of the offending MXes.
>
> if ipv4 is still working you could
> - modify your local dns resolver to strip the AAAA part in it's answer
> for the hosts in question
I thought about that, but the domains in question use DNSSEC and I
> Darren Pilgrim:
>
>> But now I have a second such doamin, and I'd like to head-off a
>> maintenance problem. All such domains use the same set of MXes, so
>> it's an obvious pattern to switch transports if the next hop is one
>> of the offending MXes.
>
> if ipv4 is still working you could
> - modify your local dns resolver to strip the AAAA part in it's answer
> for the hosts in question
generally try not to break other people's protective measures. :)
> - modify your local firewall to *reject* outbound connections to the
> IPv6 address in question
> both are not perfect any may have unwanted side effects.
static list of non-static things. Maintaining a host pattern still has
that problem, but it at least gets me some automation if they renumber
or rename their MXes, which I've seen them do.
Wietse Venema
Nov 22, 2014, 8:11:00 PM11/22/14
to
Darren Pilgrim:
or socketmap, plus some clever scripting to generate the right
transport map responses.
Otherwise this requires new Postfix code. Giving this a few minutes
of thought I came up with two designs.
My simplest design is a new configurable DNS reply filter that can
be used to ignore Google AAAA records (but it can also be used to
ignore other results).
/etc/postfix/main.cf:
smtp_dns_reply_filter = pcre:/etc/postfix/smtp_dns_reply_filter
/etc/postfix/smtp_dns_reply_filter:
# aspmx.l.google.com. 300 IN AAAA 2607:f8b0:400d:c03::1b
/^\S+\.google\.com\s+\S+\s+\S+\s+aaaa/ ignore
This would go into the Postfix DNS library, where it can be used
to filter queries by all Postfix programs, and provide a new kind
of rope that people can shoot themselves into the feet with.
Downside of this is that it can filter only on things that Postfix
asks for. For example, it cannot be used to filter on Google's NS
records because the Postfix SMTP client does not ask for those.
My not-so-simple design involves a new DNS-based lookup table and
a configurable SMTP client policy table.
/etc/postfix/main.cf:
smtp_policy_maps = pipemap:{dns:mx, pcre:/etc/postfix/dnsmx.pcre}
/etc/postfix/dnsmx.pcre:
/\.google\.com$/ inet_protocols=ipv4
Query the DNS for MX records for the next-hop domain (usually the
recipient domain). Feed the results one line at a time into the
PCRE table. Disable IPv6 if at least one MX host is a Google host.
This PCRE map should probably not support $number expansions.
This feature makes its own DNS lookups, so it can make queries
that the Postfix SMTP client would not make, such as NS records.
For now, I think that the DNS reply filter is sufficient. It is
a lot simpler.
Wietse
> > if ipv4 is still working you could
> > - modify your local dns resolver to strip the AAAA part in it's answer
> > for the hosts in question
>
> I thought about that, but the domains in question use DNSSEC and I
> generally try not to break other people's protective measures. :)
>
> > - modify your local firewall to *reject* outbound connections to the
> > IPv6 address in question
> > both are not perfect any may have unwanted side effects.
>
> Considered this as well, but I'm trying to get away from maintaining a
> static list of non-static things. Maintaining a host pattern still has
> that problem, but it at least gets me some automation if they renumber
> or rename their MXes, which I've seen them do.
It could be kludged together with a transport map based on tcp_table
> > - modify your local dns resolver to strip the AAAA part in it's answer
> > for the hosts in question
>
> I thought about that, but the domains in question use DNSSEC and I
> generally try not to break other people's protective measures. :)
>
> > - modify your local firewall to *reject* outbound connections to the
> > IPv6 address in question
> > both are not perfect any may have unwanted side effects.
>
> Considered this as well, but I'm trying to get away from maintaining a
> static list of non-static things. Maintaining a host pattern still has
> that problem, but it at least gets me some automation if they renumber
> or rename their MXes, which I've seen them do.
or socketmap, plus some clever scripting to generate the right
transport map responses.
Otherwise this requires new Postfix code. Giving this a few minutes
of thought I came up with two designs.
My simplest design is a new configurable DNS reply filter that can
be used to ignore Google AAAA records (but it can also be used to
ignore other results).
/etc/postfix/main.cf:
smtp_dns_reply_filter = pcre:/etc/postfix/smtp_dns_reply_filter
/etc/postfix/smtp_dns_reply_filter:
# aspmx.l.google.com. 300 IN AAAA 2607:f8b0:400d:c03::1b
/^\S+\.google\.com\s+\S+\s+\S+\s+aaaa/ ignore
This would go into the Postfix DNS library, where it can be used
to filter queries by all Postfix programs, and provide a new kind
of rope that people can shoot themselves into the feet with.
Downside of this is that it can filter only on things that Postfix
asks for. For example, it cannot be used to filter on Google's NS
records because the Postfix SMTP client does not ask for those.
My not-so-simple design involves a new DNS-based lookup table and
a configurable SMTP client policy table.
/etc/postfix/main.cf:
smtp_policy_maps = pipemap:{dns:mx, pcre:/etc/postfix/dnsmx.pcre}
/etc/postfix/dnsmx.pcre:
/\.google\.com$/ inet_protocols=ipv4
Query the DNS for MX records for the next-hop domain (usually the
recipient domain). Feed the results one line at a time into the
PCRE table. Disable IPv6 if at least one MX host is a Google host.
This PCRE map should probably not support $number expansions.
This feature makes its own DNS lookups, so it can make queries
that the Postfix SMTP client would not make, such as NS records.
For now, I think that the DNS reply filter is sufficient. It is
a lot simpler.
Wietse
Darren Pilgrim
Nov 22, 2014, 11:16:08 PM11/22/14
to
avoids the DNSSEC invalidation issue with filtering DNS responses.
Let's say the first next hop is an IPv4-only host, but later MXes have
IPv6. Will filtering out A records result in Postfix logging a "host
not found" error and safely moving to the next MX? If so, should the
dns reply filter also log discarded RRs?
Viktor Dukhovni
Nov 23, 2014, 12:44:09 AM11/23/14
to
On Sat, Nov 22, 2014 at 08:10:38PM -0500, Wietse Venema wrote:
> Otherwise this requires new Postfix code. Giving this a few minutes
> of thought I came up with two designs.
>
> My simplest design is a new configurable DNS reply filter that can
> be used to ignore Google AAAA records (but it can also be used to
> ignore other results).
>
> /etc/postfix/main.cf:
> smtp_dns_reply_filter = pcre:/etc/postfix/smtp_dns_reply_filter
>
> [...]
> Otherwise this requires new Postfix code. Giving this a few minutes
> of thought I came up with two designs.
>
> My simplest design is a new configurable DNS reply filter that can
> be used to ignore Google AAAA records (but it can also be used to
> ignore other results).
>
> /etc/postfix/main.cf:
> smtp_dns_reply_filter = pcre:/etc/postfix/smtp_dns_reply_filter
>
>
> My not-so-simple design involves a new DNS-based lookup table and
> a configurable SMTP client policy table.
>
> /etc/postfix/main.cf:
> smtp_policy_maps = pipemap:{dns:mx, pcre:/etc/postfix/dnsmx.pcre}
>
> /etc/postfix/dnsmx.pcre:
> /\.google\.com$/ inet_protocols=ipv4
I have a third design (and implementation).
> My not-so-simple design involves a new DNS-based lookup table and
> a configurable SMTP client policy table.
>
> /etc/postfix/main.cf:
> smtp_policy_maps = pipemap:{dns:mx, pcre:/etc/postfix/dnsmx.pcre}
>
> /etc/postfix/dnsmx.pcre:
> /\.google\.com$/ inet_protocols=ipv4
/etc/postfix/main.cf:
inet_protocols = any
smtp_inet_protocol_host_maps = texthash:${config_directory}/inet_protocols
/etc/postfix/inet_protocols:
.google.com ipv4
The attached patch is missing only the internal developer documentation
for the new inet_proto_lookup() function. It applies to Postfix
2.12 snapshots. [ It conflicts with the IDNA for TLS patch I sent
off-list to Wietse in that a new header file #include is added to
src/smtp/smtp_addr.c in the same place by both patches. ]
--
Viktor.
Peter
Nov 23, 2014, 4:47:13 AM11/23/14
to
On 11/23/2014 02:10 PM, Wietse Venema wrote:
> It could be kludged together with a transport map based on tcp_table
> or socketmap, plus some clever scripting to generate the right
> transport map responses.
I think a more elegant solution that should work would be to create a
> It could be kludged together with a transport map based on tcp_table
> or socketmap, plus some clever scripting to generate the right
> transport map responses.
policy daemon that would be coded to look up MX records for the
recipient domain and return a result based on a table match (could stub
postmap -q for the table lookups). This could be made as a simple
add-on to postfix that doesn't require any patching or new code to
implement so it would work on older versions of postfix as well as new.
Peter
Viktor Dukhovni
Nov 23, 2014, 2:09:57 PM11/23/14
to
On Sun, Nov 23, 2014 at 05:43:44AM +0000, Viktor Dukhovni wrote:
> It applies to Postfix
> 2.12 snapshots. [ It conflicts with the IDNA for TLS patch I sent
> off-list to Wietse in that a new header file #include is added to
> src/smtp/smtp_addr.c in the same place by both patches. ]
Oops that conflict was imaginary, I added midna.h to tls_client.c
> It applies to Postfix
> 2.12 snapshots. [ It conflicts with the IDNA for TLS patch I sent
> off-list to Wietse in that a new header file #include is added to
> src/smtp/smtp_addr.c in the same place by both patches. ]
not smtp_addr.c. So I edited the patch in error. Corrected
patch attached. This applies to 2.12-20141119 with or without
the off-list IDNA enhancements for TLS.
--
Viktor.
Wietse Venema
Nov 23, 2014, 2:17:38 PM11/23/14
to
Viktor Dukhovni:
I have a preference for the design that addresses the problem at a
lower level in the stack, so that the solution is not limited to
the SMTP client and not limited to inet protocol selection.
That code can then also be used to address other forms of trouble
that manifest themselves via DNS (for example the next time someone
changes the meaning of some corner case, like nullmx).
I have a draft implementation that is being tested.
Wietse
lower level in the stack, so that the solution is not limited to
the SMTP client and not limited to inet protocol selection.
That code can then also be used to address other forms of trouble
that manifest themselves via DNS (for example the next time someone
changes the meaning of some corner case, like nullmx).
I have a draft implementation that is being tested.
Wietse
Darren Pilgrim
Nov 23, 2014, 8:26:23 PM11/23/14
to
Peter
Nov 23, 2014, 11:42:49 PM11/23/14
to
On 11/24/2014 02:25 PM, Darren Pilgrim wrote:
> You can't use policy services with the smtp client, only the smtp server.
Weitse's proposal to use tcp tables is probably a better approach
> You can't use policy services with the smtp client, only the smtp server.
anyways, but you can use a policy daemon and route from smtpd. The
point is you're routing *from* smtpd to a specific smtp transport.
Peter
Darren Pilgrim
Nov 24, 2014, 10:35:45 AM11/24/14
to
message to cleanup.
Wietse Venema
Nov 24, 2014, 11:04:04 AM11/24/14
to
Darren Pilgrim:
Under very limited conditions, an SMTPD access table or policy
server can specify a filter action like this:
FILTER ipv4-only-transport:
This will send mail over the ipv4-only-transport to the SMTP
destination host.
Wietse
server can specify a filter action like this:
FILTER ipv4-only-transport:
This will send mail over the ipv4-only-transport to the SMTP
destination host.
Wietse
Darren Pilgrim
Nov 24, 2014, 11:37:53 AM11/24/14
to
recipients. You could receive by one instance, then relay to a second
instance via an transport that sets the recipient limit to 1. That
second instance could then use the FILTER directive reliabily. IMO
that's even more kludgy than using a socketmap daemon with transport
maps, though.
Viktor Dukhovni
Nov 24, 2014, 12:51:46 PM11/24/14
to
On Sun, Nov 23, 2014 at 02:17:23PM -0500, Wietse Venema wrote:
> I have a preference for the design that addresses the problem at a
> lower level in the stack, so that the solution is not limited to
> the SMTP client and not limited to inet protocol selection.
>
> That code can then also be used to address other forms of trouble
> that manifest themselves via DNS (for example the next time someone
> changes the meaning of some corner case, like nullmx).
>
> I have a draft implementation that is being tested.
Feel free to compare notes. The code changes in inet_proto.c are
> I have a preference for the design that addresses the problem at a
> lower level in the stack, so that the solution is not limited to
> the SMTP client and not limited to inet protocol selection.
>
> That code can then also be used to address other forms of trouble
> that manifest themselves via DNS (for example the next time someone
> changes the meaning of some corner case, like nullmx).
>
> I have a draft implementation that is being tested.
for example policy neutral, this just supports on-the-fly protocol
settings for whatever code happens to want such data. I forgot to
include one last change for that module, that avoids too large a
mask array should we ever support more than 2 protocols. (2^2^n
happens to equal 2*2^n for n=1,2).
diff --git a/src/util/inet_proto.c b/src/util/inet_proto.c
index 31b1ac1..d572c47 100644
--- a/src/util/inet_proto.c
+++ b/src/util/inet_proto.c
@@ -131,7 +131,7 @@ static const NAME_MASK proto_table[] = {
/*
* Cache by mask value.
*/
-static INET_PROTO_INFO *info_by_mask[1<<INET_PROTO_MASK_LAST];
+static INET_PROTO_INFO *info_by_mask[INET_PROTO_MASK_LAST<<1];
/* make_uchar_vector - create and initialize uchar vector */
I hope the low level mechanism in question will apply with some
specificity, e.g. for particular MX hosts among many for the same
nexthop domain. Some domains mix Google and non-google MX hosts.
If some day their non-Google MX hosts only support IPv6, we might
inadverantly disable these entirely:
kortingisleuk.nl. IN MX 10 kortingisleuk.nl.
kortingisleuk.nl. IN A 85.17.142.4
kortingisleuk.nl. IN MX 10 ASPMX.L.GOOGLE.COM.
kortingisleuk.nl. IN MX 20 ALT1.ASPMX.L.GOOGLE.COM.
kortingisleuk.nl. IN MX 20 ALT2.ASPMX.L.GOOGLE.COM.
kortingisleuk.nl. IN MX 30 ASPMX2.GOOGLEMAIL.COM.
kortingisleuk.nl. IN MX 30 ASPMX3.GOOGLEMAIL.COM.
kortingisleuk.nl. IN MX 30 ASPMX4.GOOGLEMAIL.COM.
kortingisleuk.nl. IN MX 30 ASPMX5.GOOGLEMAIL.COM.
Likewise, were someone to chose to only use IPv6 with Google some
day.
--
Viktor.
Wietse Venema
Nov 24, 2014, 1:38:41 PM11/24/14
to
Viktor Dukhovni:
use case is to drop *.google.com AAAA records while passing on all
other AAAA records.
postscreen_dns_reply_filter (default: $default_dns_reply_filter)
...
smtp_dns_reply_filter (default: $default_dns_reply_filter)
...
smtpd_dns_reply_filter (default: $default_dns_reply_filter)
...
default_dns_reply_filter (default: empty)
...
Example: ignore Google AAAA records in Postfix SMTP client DNS lookups,
because Google sometimes hard-rejects mail from IPv6 clients with valid
PTR etc. records.
/etc/postfix/smtp_dns_reply_filter:
# /domain ttl IN AAAA address/ action, all case-insensitive.
# Note: the domain name ends in ".".
/^\S+\.google.com\.\s+\S+\s+\S+\s+AAAA\s+/ IGNORE
The implementation renders a DNS record as a string in the format
that we know from dig(1) and other tools, then matches that string
against a list of lookup tables. Currently, IGNORE is the only
implemented action. It removes the record from the DNS lookup result.
When all DNS lookup result reply records are deleted, it returns a
DNS_NOTFOUND status plus a diagnostic text with "All records
suppressed by policy filter".
Wietse
> On Sun, Nov 23, 2014 at 02:17:23PM -0500, Wietse Venema wrote:
>
> > I have a preference for the design that addresses the problem at a
> > lower level in the stack, so that the solution is not limited to
> > the SMTP client and not limited to inet protocol selection.
> >
> > That code can then also be used to address other forms of trouble
> > that manifest themselves via DNS (for example the next time someone
> > changes the meaning of some corner case, like nullmx).
> >
> > I have a draft implementation that is being tested.
>
>
> > I have a preference for the design that addresses the problem at a
> > lower level in the stack, so that the solution is not limited to
> > the SMTP client and not limited to inet protocol selection.
> >
> > That code can then also be used to address other forms of trouble
> > that manifest themselves via DNS (for example the next time someone
> > changes the meaning of some corner case, like nullmx).
> >
> > I have a draft implementation that is being tested.
>
> I hope the low level mechanism in question will apply with some
> specificity, e.g. for particular MX hosts among many for the same
> nexthop domain. Some domains mix Google and non-google MX hosts.
It can drop DNS records based on arbitrary criteria, but the initial
> specificity, e.g. for particular MX hosts among many for the same
> nexthop domain. Some domains mix Google and non-google MX hosts.
use case is to drop *.google.com AAAA records while passing on all
other AAAA records.
postscreen_dns_reply_filter (default: $default_dns_reply_filter)
...
smtp_dns_reply_filter (default: $default_dns_reply_filter)
...
smtpd_dns_reply_filter (default: $default_dns_reply_filter)
...
default_dns_reply_filter (default: empty)
...
Example: ignore Google AAAA records in Postfix SMTP client DNS lookups,
because Google sometimes hard-rejects mail from IPv6 clients with valid
PTR etc. records.
/etc/postfix/smtp_dns_reply_filter:
# /domain ttl IN AAAA address/ action, all case-insensitive.
# Note: the domain name ends in ".".
/^\S+\.google.com\.\s+\S+\s+\S+\s+AAAA\s+/ IGNORE
The implementation renders a DNS record as a string in the format
that we know from dig(1) and other tools, then matches that string
against a list of lookup tables. Currently, IGNORE is the only
implemented action. It removes the record from the DNS lookup result.
When all DNS lookup result reply records are deleted, it returns a
DNS_NOTFOUND status plus a diagnostic text with "All records
suppressed by policy filter".
Wietse
Viktor Dukhovni
Nov 25, 2014, 11:07:01 AM11/25/14
to
On Mon, Nov 24, 2014 at 01:38:15PM -0500, Wietse Venema wrote:
> /etc/postfix/smtp_dns_reply_filter:
> # /domain ttl IN AAAA address/ action, all case-insensitive.
> # Note: the domain name ends in ".".
> /^\S+\.google.com\.\s+\S+\s+\S+\s+AAAA\s+/ IGNORE
>
> The implementation renders a DNS record as a string in the format
> that we know from dig(1) and other tools, then matches that string
> against a list of lookup tables. Currently, IGNORE is the only
> implemented action. It removes the record from the DNS lookup result.
>
> When all DNS lookup result reply records are deleted, it returns a
> DNS_NOTFOUND status plus a diagnostic text with "All records
> suppressed by policy filter".
There might be cases in which "DNS_NOTFOUND" should be replaced
> /etc/postfix/smtp_dns_reply_filter:
> # /domain ttl IN AAAA address/ action, all case-insensitive.
> # Note: the domain name ends in ".".
> /^\S+\.google.com\.\s+\S+\s+\S+\s+AAAA\s+/ IGNORE
>
> The implementation renders a DNS record as a string in the format
> that we know from dig(1) and other tools, then matches that string
> against a list of lookup tables. Currently, IGNORE is the only
> implemented action. It removes the record from the DNS lookup result.
>
> When all DNS lookup result reply records are deleted, it returns a
> DNS_NOTFOUND status plus a diagnostic text with "All records
> suppressed by policy filter".
with "DNS_FAIL" if as a result the RRset becomes empty.
For example, if a domain has MX records, but we drop them all, it
may not be appropriate to then use the A/AAAA records. Rather, it
seems that such a domain is unreachable. So the "IGNORE" could
be augmented by:
IGNORE_FAIL_IF_EMPTY
or some such.
--
Viktor.
Darren Pilgrim
Nov 25, 2014, 11:10:53 AM11/25/14
to
want "defer if empty" with logging stating that the set of A/AAAA
nexthops is empty after filtering. That way I'm not bouncing email on
what could, ironically, be a transient DNS issue.
Viktor Dukhovni
Nov 25, 2014, 11:49:07 AM11/25/14
to
On Tue, Nov 25, 2014 at 08:10:28AM -0800, Darren Pilgrim wrote:
> >For example, if a domain has MX records, but we drop them all, it
> >may not be appropriate to then use the A/AAAA records. Rather, it
> >seems that such a domain is unreachable. So the "IGNORE" could
> >be augmented by:
> >
> > IGNORE_FAIL_IF_EMPTY
>
> I can definitely see the utility of that. I think in production I would
> want "defer if empty" with logging stating that the set of A/AAAA nexthops
> is empty after filtering. That way I'm not bouncing email on what could,
> ironically, be a transient DNS issue.
Well, actual DNS answers are not supposed to be transient issues, those
> >For example, if a domain has MX records, but we drop them all, it
> >may not be appropriate to then use the A/AAAA records. Rather, it
> >seems that such a domain is unreachable. So the "IGNORE" could
> >be augmented by:
> >
> > IGNORE_FAIL_IF_EMPTY
>
> I can definitely see the utility of that. I think in production I would
> want "defer if empty" with logging stating that the set of A/AAAA nexthops
> is empty after filtering. That way I'm not bouncing email on what could,
> ironically, be a transient DNS issue.
are the result of timeouts and other lookup failures, however, if we
provide the hard-fail feature, creating a soft-fail variant is perhaps
not unreasonable as a matter of completeness.
--
Viktor.
Darren Pilgrim
Nov 25, 2014, 12:00:25 PM11/25/14
to
It's not the common fault case, but I've seen it happen.
Wietse Venema
Nov 25, 2014, 4:13:35 PM11/25/14
to
Viktor Dukhovni:
is needed in the user interface.
Specifically, if the filter uses a distinct status for "all records
deleted", e.g., DNS_POLICY, then the caller already knows if that
means "record not found" (most queries) or "service unavailable"
(MX queries, or other queries for records with MX-like behavior).
Whether "empty" is a hard or soft error is a different matter. We
could have IGNORE -> DNS_POLICY, and SOFT_IGNORE -> DNS_RETRY (but
only when all records are deleted).
Wietse
> On Mon, Nov 24, 2014 at 01:38:15PM -0500, Wietse Venema wrote:
>
> > /etc/postfix/smtp_dns_reply_filter:
> > # /domain ttl IN AAAA address/ action, all case-insensitive.
> > # Note: the domain name ends in ".".
> > /^\S+\.google.com\.\s+\S+\s+\S+\s+AAAA\s+/ IGNORE
> >
> > The implementation renders a DNS record as a string in the format
> > that we know from dig(1) and other tools, then matches that string
> > against a list of lookup tables. Currently, IGNORE is the only
> > implemented action. It removes the record from the DNS lookup result.
> >
> > When all DNS lookup result reply records are deleted, it returns a
> > DNS_NOTFOUND status plus a diagnostic text with "All records
> > suppressed by policy filter".
>
> There might be cases in which "DNS_NOTFOUND" should be replaced
> with "DNS_FAIL" if as a result the RRset becomes empty.
I don't think that the distinction between different kinds of "empty"
>
> > /etc/postfix/smtp_dns_reply_filter:
> > # /domain ttl IN AAAA address/ action, all case-insensitive.
> > # Note: the domain name ends in ".".
> > /^\S+\.google.com\.\s+\S+\s+\S+\s+AAAA\s+/ IGNORE
> >
> > The implementation renders a DNS record as a string in the format
> > that we know from dig(1) and other tools, then matches that string
> > against a list of lookup tables. Currently, IGNORE is the only
> > implemented action. It removes the record from the DNS lookup result.
> >
> > When all DNS lookup result reply records are deleted, it returns a
> > DNS_NOTFOUND status plus a diagnostic text with "All records
> > suppressed by policy filter".
>
> There might be cases in which "DNS_NOTFOUND" should be replaced
> with "DNS_FAIL" if as a result the RRset becomes empty.
is needed in the user interface.
Specifically, if the filter uses a distinct status for "all records
deleted", e.g., DNS_POLICY, then the caller already knows if that
means "record not found" (most queries) or "service unavailable"
(MX queries, or other queries for records with MX-like behavior).
Whether "empty" is a hard or soft error is a different matter. We
could have IGNORE -> DNS_POLICY, and SOFT_IGNORE -> DNS_RETRY (but
only when all records are deleted).
Wietse
0 new messages