qmail-remote: remove flagcname, deprecated feature #121

leahneukirchen · 2020-04-08T21:38:06Z

qmail-remote used to rewrite the RCPT TO: domain when it was a CNAME,
as it was common before 2001.

RFC 5321 (from 2008), Section 5.1 clearly specifies what MTA should do
today:

The lookup first attempts to locate an MX record associated with the
name. If a CNAME record is found, the resulting name is processed as
if it were the initial name.

djb wrote in https://cr.yp.to/im/cname.html:

Most implementors agree that this feature is not worth the
implementation costs. I recommend that, before January 2001, sites stop
relying on client-side CNAME translation, so that implementors can
safely remove the feature at that time.

Fixes #120.

DerDakon · 2020-04-09T07:10:33Z

At first glance looks good. If you change the interface of a function please convert it to C89 style.

leahneukirchen · 2020-04-10T15:50:02Z

If someone knows about the idea behind if (flagallaliases) prefme = 500000; i'd be curious to learn about it.

DerDakon · 2020-04-10T16:39:49Z

In general I think this is correct. I have not really looked into the code, i.e. what it is actually doing, and I don't want this in 1.08 if we don't agree on that on a broader scope. So, no +1 for me for the moment, but it will likely happen.

leahneukirchen · 2020-04-10T17:05:44Z

Sure, this has been wrong since 2008 so one release more or less doesn't matter. ;)

josuah · 2020-04-13T17:50:53Z

If someone knows about the idea behind if (flagallaliases) prefme = 500000; i'd be curious to learn about it.

prefme is compared with .pref from that ipalloc struct (an array of struct { ip; pref; }).

What is .pref and where is it taking its data from?

In dns.c:int dns_mxip(ipalloc *ia, stralloc *sa, unsigned long random);, we have a call to findmx(), iterated to scan all the MX records found from DNS.

The position, preference and IP of the MX record are passed through static global variables to dns_mxip() (why not... no threads).

For each result, ia is filled with the IPs one by one through static int dns_ipplus(ipalloc *ia, stralloc *sa, int pref), and that is where qmail-remote gets its list of preferences: from DNS only, no configuration impacting ip[].ix.pref at all.

What is the effect of comparing prefme with each ip[].ix.pref from DNS?

Just below if (flagallaliases) prefme = 500000;, it chooses the first ip.[].ix.pref ip that is lower than the prefme threshold.

Just above if (flagallaliases) prefme = 500000;, the loop finds the lowest pref value for IPs matching those of the server (SIOCGIFCONF) and store it into pref.

That filters out all the MX entries that have a lower preference than qmail's own IPs. That looks like having the effect of capturing the mail in case qmail-remote has to send it out, but the server it send it to has the same IP (in other words: send a mail to myself through IP).

It is still possible to send a mail to another mail server among the MX entries, even if there is an IP of the local interface in the pool of MX responses : with a lower MX than the one that match our IPs.

This looks like a safeguard against misconfiguration: a mail for a same IP as one of which qmail listen on needs to be send through qmail-local, not through qmail-remote!

Why a high value for prefme in some cases?

When the mail server needs to relay everything to somewhere (special case), or for these addrmangle cases (tricky cases), qmail-remote bypasses this mechanism: allow all ips regardless of the context, and gonna do what it gotta do what it gotta do: forward to the first of the IPs found.

Why 500000, why not 5725 or 42?

No idea! Debugging purposes? https://tools.ietf.org/html/rfc1035#section-3.3.9 says int16, so it maxes out to 65536.

A printf() (sorry, buffer_putn() :P) after the two loop would show whether the mechanism was triggered or not.

A note on anycast BGP

In some situations, a public address might be at the same time on the interface onto which qmail listens, and another remote host, all that legitimately: Anycast BGP, for which the same IP is announced at multiple places, and the routing will make it go to the closest available.

The safeguard mechanism will still match the semantics of anycast BGP: if it reached any of that host with the one IP declared in DNS, the mail is home. If there is something more to do (like backup to master mx transfer), a lower priority has can be setup, and the mail will never be stuck on a relay, even if the same IP is on multiple hosts ("weird setups").

[EDIT: is there any place where we may document the working of qmail? On the wiki/website, in the repo on text files? That could help with consolidating/checking what we understand of qmail, and help newcomers (that I still am) to understand the context of what they touch]

leahneukirchen · 2020-04-13T18:01:19Z

The purpose of the prefme loop is to always forward mail to a higher-priority (= lower number) MX; if we are a relayhost, any MX is good.

But why the special case for flagallaliases?

josuah · 2020-04-13T22:13:10Z

I am not sure.

I imagine it is so that it is actually sent out, even if it is to the same server, so that it goes through the whole chain with the new domain name, in case it behaves differently

DerDakon · 2020-04-14T09:42:06Z

I'm not sure either, as from all I can see there can never be a pref > 0xffff. It is set in dns_mxip() to the 16 bit value from the DNS, or in dns_ip() to 0. It feels a bit like body-stripping, let it rest in pieces.

DerDakon · 2020-05-01T10:39:50Z

I have looked around a bit, and not even the SPF patch uses dns_cname(), so I guess there is no use for it anymore.

This also needs a changelog entry and the corresponding sections from the FAQ should be removed.

mbhangui · 2020-05-01T12:43:52Z

On Fri, 1 May 2020 at 16:10, Rolf Eike Beer ***@***.***> wrote: I have looked around a bit, and not even the SPF patch uses dns_cname(), so I guess there is no use for it anymore. This also needs a changelog entry and the corresponding sections from the FAQ should be removed.

There is one more target in Makefile - dnscname.c. It uses dns_cname() and it gets compiled and linked but doesn't get installed as it is not in hier.c. So this code is just lying there without any real use. This too needs to be removed.

leahneukirchen · 2020-05-01T12:49:29Z

This is already gone in master, I think:
CHANGES:20190822 cleanup: remove unused dnscname.

123fa00

DerDakon · 2020-05-01T15:36:58Z

From my feeling the last two patches should be squashed into the first one, which actually removed that feature. The other ones could optionally be squashed in or just kept as they are.

schmonz · 2020-05-01T20:16:06Z

qmail-remote.c

  }
  if (!stralloc_copys(&canonbox,s)) temp_nomem();
  canonbox.len = j;
+  /* box has to be quoted */


Seems clear enough already from the following line.

Oh, I see now this was the still-relevant part of the comment from old line 279. I’m okay keeping or getting rid of it, either way.

schmonz · 2020-06-14T13:18:59Z

qmail-remote.c

  }
  if (!stralloc_copys(&canonbox,s)) temp_nomem();
  canonbox.len = j;
+  /* box has to be quoted */


Oh, I see now this was the still-relevant part of the comment from old line 279. I’m okay keeping or getting rid of it, either way.

qmail-remote used to rewrite the RCPT TO: domain when it was a CNAME, as it was common before 2001. RFC 5321 (from 2008), Section 5.1 clearly specifies what MTA should do today: The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found, the resulting name is processed as if it were the initial name. djb wrote in https://cr.yp.to/im/cname.html: Most implementors agree that this feature is not worth the implementation costs. I recommend that, before January 2001, sites stop relying on client-side CNAME translation, so that implementors can safely remove the feature at that time. Fixes notqmail#120.

DerDakon requested review from DerDakon, alanpost, jlmuir, mbhangui, schmonz and xenotrope April 9, 2020 07:10

mbhangui approved these changes Apr 10, 2020

View reviewed changes

leahneukirchen force-pushed the addrmangle branch from 1e565b6 to 3e80936 Compare April 10, 2020 15:49

leahneukirchen force-pushed the addrmangle branch from 3e80936 to 544013c Compare April 10, 2020 16:05

leahneukirchen force-pushed the addrmangle branch from 544013c to d2e6815 Compare April 22, 2020 12:45

leahneukirchen force-pushed the addrmangle branch from ab2bc34 to f176b64 Compare May 1, 2020 15:45

schmonz reviewed May 1, 2020

View reviewed changes

DerDakon requested a review from josuah May 23, 2020 10:39

leahneukirchen force-pushed the addrmangle branch from f176b64 to 6f9fa93 Compare May 23, 2020 13:12

leahneukirchen changed the title ~~Addrmangle~~ qmail-remote: remove flagcname, deprecated feature May 23, 2020

leahneukirchen force-pushed the addrmangle branch from 6f9fa93 to 956fbbf Compare June 14, 2020 13:12

schmonz approved these changes Jun 14, 2020

View reviewed changes

DerDakon approved these changes Jun 14, 2020

View reviewed changes

leahneukirchen added 3 commits June 14, 2020 16:23

qmail-remote: remove flagalias and flagallaliases, now useless

2858e23

dns: remove dns_cname, unused.

8182595

leahneukirchen force-pushed the addrmangle branch from 956fbbf to 8182595 Compare June 14, 2020 14:24

leahneukirchen merged commit 7636386 into notqmail:master Jun 14, 2020

leahneukirchen deleted the addrmangle branch June 14, 2020 14:33

schmonz modified the milestones: 1.90, 1.09 Sep 23, 2023

qmail-remote: remove flagcname, deprecated feature #121

qmail-remote: remove flagcname, deprecated feature #121

Uh oh!

Conversation

leahneukirchen commented Apr 8, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DerDakon commented Apr 9, 2020

Uh oh!

leahneukirchen commented Apr 10, 2020

Uh oh!

DerDakon commented Apr 10, 2020

Uh oh!

leahneukirchen commented Apr 10, 2020

Uh oh!

josuah commented Apr 13, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What is .pref and where is it taking its data from?

What is the effect of comparing prefme with each ip[].ix.pref from DNS?

Why a high value for prefme in some cases?

Why 500000, why not 5725 or 42?

A note on anycast BGP

Uh oh!

leahneukirchen commented Apr 13, 2020

Uh oh!

josuah commented Apr 13, 2020

Uh oh!

DerDakon commented Apr 14, 2020

Uh oh!

DerDakon commented May 1, 2020

Uh oh!

mbhangui commented May 1, 2020 via email

Uh oh!

leahneukirchen commented May 1, 2020

Uh oh!

DerDakon commented May 1, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

schmonz May 1, 2020

Choose a reason for hiding this comment

Uh oh!

schmonz Jun 14, 2020

Choose a reason for hiding this comment

Uh oh!

schmonz Jun 14, 2020

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

leahneukirchen commented Apr 8, 2020 •

edited

Loading

josuah commented Apr 13, 2020 •

edited

Loading

DerDakon commented May 1, 2020 •

edited

Loading