OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: iddd.tpc.int CNAME oddity
From: Darren Nickerson (darrendazza.org)
Date: Tue Jun 13 2000 - 12:46:34 CDT

Thanks for this suggestion Wietse! I finally got a spare moment to build
Postfix with PCRE enabled. (you might want to read the context included below
to refresh your memory . . . this was a few weeks ago now).

I have created:

[roothewes postfix]# cat /etc/postfix/cleanup_pcre
/^(\d)(\d)(\d)(\d)(\d)(\d)(\d)(\d)(\d)(\d)(\d)\.iddd\.tpc\.int$/
$11.$10.$9.$8.$7.$6.$5.$4.$3.$2.$1.tpc.int

In main.cf I have:

canonical_maps = pcre:/etc/postfix/cleanup_pcre
relay_domains = $mydestination, localhost.$mydomain, tpc.int

And I have restarted postfix. Yet I see:

Jun 13 08:51:11 hewes postfix/smtp[25319]: 388E45F9F8:
to=<remote-printer.some_person/new_delhi91116124484.iddd.tpc.int>,
relay=none, delay=3, status=bounced (mail for 91116124484.iddd.tpc.int loops
back to myself)

dig tells me the following about MX records:

;; ANSWER SECTION:
91116124484.iddd.tpc.int. 10M IN CNAME 4.8.4.4.2.1.6.1.1.1.9.tpc.int.
4.8.4.4.2.1.6.1.1.1.9.tpc.int. 19h30m5s IN MX 20 uucp.tpc.int.

and the postfix in question is running on uucp.tpc.int.

Seems to me like postfix does not think the mail is local. When the envelope
address is actually properly canonicalised by the originating MTA it looks
like:

remote-printer.some_person/new_delhi4.8.4.4.2.1.6.1.1.1.9.tpc.int

and that does get delivered just fine thanks to a transport entry:

[roothewes postfix]# cat transports/UUCP_9111_Delhi_weblink
.1.1.1.9.tpc.int uucp:weblink

So I guess my question is this. Is there something I have forgotten to add? Is
there a problem using your PCRE canonical maps in combination with transports
and relay domains?? How do I convince postfix to accept this mail!!??

Thanks!

-Darren

>>>>> On Sun, 28 May 2000, "Wietse" == Wietse Venema wrote:

  Wietse> If the client sends aliases, and if you haven't got the aliases
  Wietse> listed in your routing maps, then you will have to do some work in
  Wietse> your canonical mappings.

  Wietse> I recommend using a PCRE table.

  Wietse> Another possibility is to copy the Postfix SMTP client's code
  Wietse> that replaces aliases by official names.

  Wietse> The PCRE solution looks like this:

  Wietse> /etc/postfix/main.cf:
  Wietse> canonical_maps = pcre:/etc/postfix/cleanup_pcre

  Wietse> /etc/postfix/cleanup_pcre
  Wietse> /^(\d)(\d)(\d)(\d)(\d)(\d)(\d)(\d)(\d)(\d)(\d)\.iddd\.tpc\.int$/
  Wietse> $11.$10.$9.$8.$7.$6.$5.$4.$3.$2.$1.iddd.tpc.int

  Wietse> This takes care of:

  Wietse> 16177401086.iddd.tpc.int -> 6.8.0.1.0.4.7.7.1.6.1.iddd.tpc.int

  Wietse> You can't use regexps for this, because those support no more than
  Wietse> 9 substitutions.

  Wietse> Wietse

  Wietse> Darren Nickerson:

  +> Folks,

  +> The TPC.INT project, which I administer when I have my "Arlington Hewes"
hat
  +> on, employs a smart little hack to BIND to convert a domain of the form:

  +> 16177401086.iddd.tpc.int

  +> to a less human-friendly (but necessary) form of:

  +> 6.8.0.1.0.4.7.7.1.6.1.tpc.int

  +> This is called the reverse-and-dot-ified form ;-)

  +> In DNS terms, this looks like:

  +> [darrenalden1 darren]$ nslookup -q=mx 16177401086.iddd.tpc.int

  +> Server: owc1.ourwatercooler.com
  +> Address: 209.166.32.52

  +> Non-authoritative answer:
  +> 16177401086.iddd.tpc.int canonical name = 6.8.0.1.0.4.7.7.1.6.1.tpc.int
  +> 6.8.0.1.0.4.7.7.1.6.1.tpc.int preference = 10, mail exchanger =
uucp.tpc.int

  +> I'm having trouble receiving these messages with Postfix on the host
uucp.tpc.int in cases where the remote MTA/MUA have not already done the ->
CNAME->MX lookup, ie: when the SMTP envelope contains a destination of
something16177401086.iddd.tpc.int. I'm not conversant enough on the RFCs to
know if I should be doing this canonicalisation? myself, but if I don't, I see:

  +> May 28 12:14:28 hewes postfix/smtp[5979]: DB0F55FD28:
to=<remote-printer.purchase_manager16177401086.iddd.tpc.int>, relay=none,
delay=29, status=bounced (mail for 16177401086.iddd.tpc.int loops back to
myself)

  +> In the ideal case, when the client has sorted this all out before it
reaches me, the correct result is observed:

  +> May 28 12:41:43 hewes postfix/pipe[6268]: 2C11B5FD2C:
to=<rp.test6.8.0.1.0.4.7.7.1.6.1.tpc.int>, relay=uucp, delay=0, status=sent
(sglines)

  +> How can I tell postfix to think about things a bit harder if it receives
something from the iddd.tpc.int domain in the SMTP envelope? I hate to say
this, but it just worked out of the box on sendmail and I never really had to
think much about it . . . :-(

  +> -Darren