Mailing List Archive: Qmail: users

cname expand in qmail-remote

1 2

View All

Index | Next | Previous | View Threaded

pawel.panek at inet

Dec 16, 2005, 4:26 AM

Post #1 of 49 (2693 views)
Permalink

cname expand in qmail-remote

Hello,
I have noticed that qmail is still non rfc 2821 part 3.6 compliant. When
sender or reciver uses as domain name the CNAME record for another domain,
his/her domain part of address would be rewritten in MAIL FROM or/and RCPT
TO command. Since rfc 2821 which allows use of CNAME if they can be
successfully resolved to an A or MX, the MTAs are not allowed to rewrite
this addresses. Any of serious MTAs like Postfix or Exim are making such
rewritings. I think so should do qmail.
Example:
Domain department1.com is CNAME for mainsite.com
Domain department2.com is CNAME for mainsite.com
all departments and mainsite.com has MX mail.mainsite.com which is pointing
at A record 1.2.3.4
this configuration is required because mainsite.com holds main services for
whole organization and administrator can easly change ip addresses of whole
structure making changes in only one place.
When someone sends email for bob[at]department1.com using qmali MTA the mail
will be delivered to bob[at]mainsite.com. Those two addressess may belong to
two different people. In fact mail.mainsite.com will try to deliver message
to bob[at]mainsite.com or will reject if there is no such account. Don't you
think this rewritnig can cause false failures or were serious mistakes
(wrong person reading confidential mail)?
Please don't argue with me that this dns structure is broken. It is very,
very usefull if you have to manage big sites which has many incorporated
domains.
I wrote a patch for this issue. It adds new configuration file placed into
control directory. It names: expcname. This accepts only integer value
placed in first line. For 0 the expansion of cname record will be disabled
so qmail wont rewrite sender or reciver address. For 1 (or any positive
integer) qmail will expand and rewrite cname into its target. The default
value is 1 (make rewrite). I think this patch should be added to netqmail
1.05. Maybe not exactly this patch but this functionality should be added.
qmail-105.expand-cname.patch:

--- qmail-remote.c.orig 2005-06-06 16:30:41.000000000 +0200
+++ qmail-remote.c 2005-12-14 14:30:15.000000000 +0100
@@ -106,6 +106,7 @@
int timeoutconnect = 60;
int smtpfd;
int timeout = 1200;
+int expcname = 1;

int saferead(fd,buf,len) int fd; char *buf; int len;
{
@@ -297,7 +298,7 @@
if (!stralloc_cats(saout,"@")) temp_nomem();

if (!stralloc_copys(&canonhost,s + j + 1)) temp_nomem();
- if (flagcname)
+ if (flagcname && expcname)
switch(dns_cname(&canonhost)) {
case 0: *flagalias = 0; break;
case DNS_MEM: temp_nomem();
@@ -314,6 +315,7 @@
if (control_readint(&timeout,"control/timeoutremote") == -1)
temp_control();
if (control_readint(&timeoutconnect,"control/timeoutconnect") == -1)
temp_control();
+ if (control_readint(&expcname,"control/expcname") == -1) temp_control();
if (control_rldef(&helohost,"control/helohost",1,(char *) 0) != 1)
temp_control();
switch(control_readfile(&routes,"control/smtproutes",0)) {

Only 3 lines got changed so you can apply this patch manualy or use:
patch -p 0 < qmail-105.expand-cname.patch
with clean netqmail 1.05 source. The patch may be applied cleanly after
those patches:
qmail-1.03-mysql-0.7.4.patch
auth.patch
qmail-103.patch (big dns)
qmail-103.doublebounce-trim.patch
Comments will be appreciated.
Regards,
Pawel Panek
--
Image Electronics http://www.inet.pl/
Plac Rodla 8, 70-419 Szczecin, Poland
e-mail: Pawel.Panek[at]inet.pl
tel: +4891 4324200 fax: +4891 4882175

kyle-qmail at memoryhole

Dec 16, 2005, 5:55 AM

Post #2 of 49 (2642 views)
Permalink

Re: cname expand in qmail-remote [In reply to]

On Friday, December 16 at 01:26 PM, quoth Paweł Panek:
> I have noticed that qmail is still non rfc 2821 part 3.6 compliant.
> When sender or reciver uses as domain name the CNAME record for
> another domain, his/her domain part of address would be rewritten in
> MAIL FROM or/and RCPT TO command. Since rfc 2821 which allows use of
> CNAME if they can be successfully resolved to an A or MX, the MTAs are
> not allowed to rewrite this addresses. Any of serious MTAs like
> Postfix or Exim are making such rewritings. I think so should do
> qmail.

You are misreading this section. CNAMEs tell you to pretend that the
domain it points to was the original domain. This new domain can have an
A record and/or an MX record. That's what the section means.

Trust me, I would appreciate it if CNAMEs could have their own MX
records, but they just can't. Indeed, in the most recent version of
Bind, you cannot create a CNAME with an MX record: it (nsupdate) will
throw an error, like this:

updating zone 'memoryhole.net': attempt to add CNAME alongside
non-CNAME ignored

The reason is that this violates RFC 1034, section 3.6.2. Specifically:

If a CNAME RR is present at a node, no other data should be present;
this ensures that the data for a canonical name and its aliases
cannot be different.

> Example:
> Domain department1.com is CNAME for mainsite.com
> Domain department2.com is CNAME for mainsite.com
>
> all departments and all departments and mainsite.com has MX
> mail.mainsite.com which is pointing at A record 1.2.3.4
>
> this configuration is required because mainsite.com holds main services for
> whole organization and administrator can easly change ip addresses of
> whole structure making changes in only one place.

Trust me, I recognize this administrative frustration.

The only bright side is that if you're using a useful text editor, you
can use search&replace to change all the IP addresses if they need to
change.

> Please don't argue with me that this dns structure is broken. It is
> very, very usefull if you have to manage big sites which has many
> incorporated domains.

The DNS structure you are specifying is broken. And if other mailers are
obeying your broken MX records, then those mailers are broken.

~Kyle
--
In wine there is wisdom, in beer there is strength, in water there is
bacteria.
-- German proverb

pawel.panek at inet

Dec 16, 2005, 6:11 AM

Post #3 of 49 (2633 views)
Permalink

Re: cname expand in qmail-remote [In reply to]

Hi again,
I have to write once again the example for this problem. Domain names which
I used got x-ed :).
Example:
Domain department1.com is CNAME for mainsite.com
Domain department2.com is CNAME for mainsite.com
all departments and mainsite.com has MX mail.mainsite.com which is pointing
at A record 1.2.3.4
this configuration is required because mainsite.com holds main services for
whole organization and administrator can easly change ip addresses of whole
structure making changes in only one place.
When someone sends email for bob at department1 dot com using qmali MTA the
mail
will be delivered to bob at mainsite dot com. Those two addressess may
belong to
two different people. In fact mail.mainsite.com will try to deliver message
to bob at mainsite dot com or will reject if there is no such account.
Don't you
think this rewritnig can cause false failures or were serious mistakes
(wrong person reading confidential mail)?

Sorry for repeating myself. Also sorry for my English.

----- Original Message -----
From: "Pawe� Panek" <pawel.panek[at]inet.pl>
To: <qmail[at]list.cr.yp.to>
Sent: Friday, December 16, 2005 1:26 PM
Subject: cname expand in qmail-remote

> Hello,
> I have noticed that qmail is still non rfc 2821 part 3.6 compliant. When
> sender or reciver uses as domain name the CNAME record for another domain,
> his/her domain part of address would be rewritten in MAIL FROM or/and RCPT
> TO command. Since rfc 2821 which allows use of CNAME if they can be
> successfully resolved to an A or MX, the MTAs are not allowed to rewrite
> this addresses. Any of serious MTAs like Postfix or Exim are making such
> rewritings. I think so should do qmail.
> Example:
> Domain department1.com is CNAME for mainsite.com
> Domain department2.com is CNAME for mainsite.com
> all departments and mainsite.com has MX mail.mainsite.com which is
pointing
> at A record 1.2.3.4
> this configuration is required because mainsite.com holds main services
for
> whole organization and administrator can easly change ip addresses of
whole
> structure making changes in only one place.
> When someone sends email for bob[at]department1.com using qmali MTA the mail
> will be delivered to bob[at]mainsite.com. Those two addressess may belong to
> two different people. In fact mail.mainsite.com will try to deliver
message
> to bob[at]mainsite.com or will reject if there is no such account. Don't you
> think this rewritnig can cause false failures or were serious mistakes
> (wrong person reading confidential mail)?
> Please don't argue with me that this dns structure is broken. It is very,
> very usefull if you have to manage big sites which has many incorporated
> domains.
> I wrote a patch for this issue. It adds new configuration file placed into
> control directory. It names: expcname. This accepts only integer value
> placed in first line. For 0 the expansion of cname record will be disabled
> so qmail wont rewrite sender or reciver address. For 1 (or any positive
> integer) qmail will expand and rewrite cname into its target. The default
> value is 1 (make rewrite). I think this patch should be added to netqmail
> 1.05. Maybe not exactly this patch but this functionality should be added.
> qmail-105.expand-cname.patch:
>
> --- qmail-remote.c.orig 2005-06-06 16:30:41.000000000 +0200
> +++ qmail-remote.c 2005-12-14 14:30:15.000000000 +0100
> @@ -106,6 +106,7 @@
> int timeoutconnect = 60;
> int smtpfd;
> int timeout = 1200;
> +int expcname = 1;
>
> int saferead(fd,buf,len) int fd; char *buf; int len;
> {
> @@ -297,7 +298,7 @@
> if (!stralloc_cats(saout,"@")) temp_nomem();
>
> if (!stralloc_copys(&canonhost,s + j + 1)) temp_nomem();
> - if (flagcname)
> + if (flagcname && expcname)
> switch(dns_cname(&canonhost)) {
> case 0: *flagalias = 0; break;
> case DNS_MEM: temp_nomem();
> @@ -314,6 +315,7 @@
> if (control_readint(&timeout,"control/timeoutremote") == -1)
> temp_control();
> if (control_readint(&timeoutconnect,"control/timeoutconnect") == -1)
> temp_control();
> + if (control_readint(&expcname,"control/expcname") == -1)
temp_control();
> if (control_rldef(&helohost,"control/helohost",1,(char *) 0) != 1)
> temp_control();
> switch(control_readfile(&routes,"control/smtproutes",0)) {
>
> Only 3 lines got changed so you can apply this patch manualy or use:
> patch -p 0 < qmail-105.expand-cname.patch
> with clean netqmail 1.05 source. The patch may be applied cleanly after
> those patches:
> qmail-1.03-mysql-0.7.4.patch
> auth.patch
> qmail-103.patch (big dns)
> qmail-103.doublebounce-trim.patch
> Comments will be appreciated.
> Regards,
> Pawel Panek
> --
> Image Electronics http://www.inet.pl/
> Plac Rodla 8, 70-419 Szczecin, Poland
> e-mail: Pawel.Panek[at]inet.pl
> tel: +4891 4324200 fax: +4891 4882175
>
>

qmail at discworld

Dec 16, 2005, 6:35 AM

Post #4 of 49 (2635 views)
Permalink

Re: cname expand in qmail-remote [In reply to]

Pawe? Panek <pawel.panek[at]inet.pl> wrote:
>
> I have to write once again the example for this problem.

The problem is still that you're mis-reading the specifications.

> When someone sends email for bob at department1 dot com using qmali MTA the
> mail will be delivered to bob at mainsite dot com. Those two addressess may
> belong to two different people.

No. This is where your argument falls down. If "foo" is a CNAME pointing at
"bar", then <bob[at]foo> and <bob[at]bar> are /not/ "two addresses" -- they're the
same address, written in two different ways.

It's just one address, and therefore the message can't be delivered to the
wrong person.

Charles
--
--------------------------------------------------------------------------
Charles Cazabon <qmail[at]discworld.dyndns.org>
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
My services include qmail consulting. See http://pyropus.ca/ for details.
--------------------------------------------------------------------------

feizhou at graffiti

Dec 16, 2005, 6:35 AM

Post #5 of 49 (2633 views)
Permalink

Re: cname expand in qmail-remote [In reply to]

Pawe� Panek wrote:
> Hi again,
> I have to write once again the example for this problem. Domain names which
> I used got x-ed :).
> Example:
> Domain department1.com is CNAME for mainsite.com
> Domain department2.com is CNAME for mainsite.com
> all departments and mainsite.com has MX mail.mainsite.com which is pointing
> at A record 1.2.3.4
> this configuration is required because mainsite.com holds main services for
> whole organization and administrator can easly change ip addresses of whole
> structure making changes in only one place.
> When someone sends email for bob at department1 dot com using qmali MTA the
> mail
> will be delivered to bob at mainsite dot com. Those two addressess may
> belong to
> two different people. In fact mail.mainsite.com will try to deliver message
> to bob at mainsite dot com or will reject if there is no such account.
> Don't you
> think this rewritnig can cause false failures or were serious mistakes
> (wrong person reading confidential mail)?
>
> Sorry for repeating myself. Also sorry for my English.

Absolute complete misunderstanding.

Repeat after me. qmail does NOT rewrite envelope recipients or sender.

feizhou at graffiti

Dec 16, 2005, 6:53 AM

Post #6 of 49 (2639 views)
Permalink

Re: cname expand in qmail-remote [In reply to]

Pawe� Panek wrote:
> Hello,
> I have noticed that qmail is still non rfc 2821 part 3.6 compliant. When
> sender or reciver uses as domain name the CNAME record for another domain,
> his/her domain part of address would be rewritten in MAIL FROM or/and RCPT
> TO command. Since rfc 2821 which allows use of CNAME if they can be
> successfully resolved to an A or MX, the MTAs are not allowed to rewrite
> this addresses. Any of serious MTAs like Postfix or Exim are making such
> rewritings. I think so should do qmail.

Please get your head clear. Here you clearly imply, and correctly for
that matter, that qmail does not rewrite envelope headers but then you
later assert that qmail's qmail-remote program will rewrite. FYI,
postfix and exim only do rewriting when TOLD to do so. They do not
automatically mess around with envelope headers.

> Example:
> Domain department1.com is CNAME for mainsite.com
> Domain department2.com is CNAME for mainsite.com
> all departments and mainsite.com has MX mail.mainsite.com which is pointing
> at A record 1.2.3.4
> this configuration is required because mainsite.com holds main services for
> whole organization and administrator can easly change ip addresses of whole
> structure making changes in only one place.

False. You can host THOUSANDS of domains without using CNAME and easily
change the ip address(es) of the MX in only one place. This
configuration is absolutely NOT required.

> When someone sends email for bob[at]department1.com using qmali MTA the mail
> will be delivered to bob[at]mainsite.com. Those two addressess may belong to
> two different people. In fact mail.mainsite.com will try to deliver message
> to bob[at]mainsite.com or will reject if there is no such account. Don't you
> think this rewritnig can cause false failures or were serious mistakes
> (wrong person reading confidential mail)?

Nonsense. qmail will deliver to bob[at]department1.com at
mail.mainsite.com. Whatever mail.mainsite.com does with the mail (like
rewriting to bob[at]mainsite.com) is no longer qmail's responsibility.

> Please don't argue with me that this dns structure is broken. It is very,
> very usefull if you have to manage big sites which has many incorporated
> domains.

Please consider that perhaps you are not very experienced or skilled in
managing a dns server.

<snip patch that was written based on major misunderstanding>

pawel.panek at inet

Dec 16, 2005, 7:18 AM

Post #7 of 49 (2639 views)
Permalink

Re: cname expand in qmail-remote [In reply to]

hi,
Ok, I see you don't catch my point. I wrote one thing bad - the CNAMEs can't
have MX records (RFC 1034, section 3.6.2). But for this DNS structure (SOA
records are skiped):

department1.com. CNAME mainsite.com. -- this is only one RR in this domain

department2.com. CNAME mainsite.com. -- this is only one RR in this domain

mainsite.com. A 1.2.3.4
mainsite.com. MX mail.mainsite.com.
mail A 1.2.3.5

Question 1: is this dns structure broken?
Question 2: if structure isn't broken so who will get an email addressed to
bob at department1 dot com (using qmail MTA)?

My answer for question 2 is: bob at mainsite dot com - this addres will be
used in RCPT TO command. Now if you use recipient checking at smtp session
and bob at mainsite dot com doesn't exist the message will be rejected by
1.2.3.5. In another case the mail could be delivered to bob at mainsite dot
com if such box exist but bob at mainsite dot com is different person than
bob at departmet1 dot com. It is true that envelope sender and recipient
wont be rewritten. Rewriting has place only in RCPT TO and MAIL FROM
commands. I use recipient checking against MySQL database at smtp session.
All mail boxes are defined in MySQL database. When qmail is delivering
message it doesn't obey envelope recipient, its using recipient from RCPT TO
command and this is right but RCPT TO command is bad.
Is my thinking broken or cname rewritnig in qmail is broken? Please check if
some other MTAs (Postfix, Exim) are making this rewriting.
----- Original Message -----
From: "Kyle Wheeler" <kyle-qmail[at]memoryhole.net>
To: <qmail[at]list.cr.yp.to>
Sent: Friday, December 16, 2005 2:55 PM
Subject: Re: cname expand in qmail-remote

qmail at discworld

Dec 16, 2005, 7:29 AM

Post #8 of 49 (2626 views)
Permalink

Re: cname expand in qmail-remote [In reply to]

Pawe?? Panek <pawel.panek[at]inet.pl> wrote:
> In another case the mail could be delivered to bob at mainsite dot
> com if such box exist but bob at mainsite dot com is different person than
> bob at departmet1 dot com.

Impossible. Repeat: since "department1.com" is a CNAME for "mainsite.com",
they /cannot/ be different people, as <bob[at]department1.com> and
<bob[at]mainsite.com> are /the same address written different ways/.

Charles
--
--------------------------------------------------------------------------
Charles Cazabon <qmail[at]discworld.dyndns.org>
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
My services include qmail consulting. See http://pyropus.ca/ for details.
--------------------------------------------------------------------------

feizhou at graffiti

Dec 16, 2005, 7:33 AM

Post #9 of 49 (2637 views)
Permalink

Re: cname expand in qmail-remote [In reply to]

Paweł Panek wrote:
> hi,
> Ok, I see you don't catch my point. I wrote one thing bad - the CNAMEs can't
> have MX records (RFC 1034, section 3.6.2). But for this DNS structure (SOA
> records are skiped):
>
> department1.com. CNAME mainsite.com. -- this is only one RR in this domain
>
> department2.com. CNAME mainsite.com. -- this is only one RR in this domain
>
> mainsite.com. A 1.2.3.4
> mainsite.com. MX mail.mainsite.com.
> mail A 1.2.3.5
>
> Question 1: is this dns structure broken?

Yeah. I would make it:

department1.com. IN A 1.2.3.4
department1.com. IN MX 10 mail.department1.com.
mail IN A 1.2.3.5

repeat the above for all other domains.

mainsite.com. IN A 1.2.3.4
mainsite.com. IN MX 10 mail.mainsite.com.
mail IN A 1.2.3.5

I take it you use bind. Have you heard of the $INCLUDE directive?

> Question 2: if structure isn't broken so who will get an email addressed to
> bob at department1 dot com (using qmail MTA)?
>
> My answer for question 2 is: bob at mainsite dot com - this addres will be
> used in RCPT TO command. Now if you use recipient checking at smtp session

Absolute nonsense. The answer is it depends on how you configure qmail.

> and bob at mainsite dot com doesn't exist the message will be rejected by
> 1.2.3.5. In another case the mail could be delivered to bob at mainsite dot
> com if such box exist but bob at mainsite dot com is different person than
> bob at departmet1 dot com. It is true that envelope sender and recipient
> wont be rewritten. Rewriting has place only in RCPT TO and MAIL FROM

You have no idea what you are talking about. qmail DOES NOT rewrite period.

> commands. I use recipient checking against MySQL database at smtp session.
> All mail boxes are defined in MySQL database. When qmail is delivering
> message it doesn't obey envelope recipient, its using recipient from RCPT TO
> command and this is right but RCPT TO command is bad.

You have no idea what you are talking about.

> Is my thinking broken or cname rewritnig in qmail is broken? Please check if
> some other MTAs (Postfix, Exim) are making this rewriting.

Like I said, postfix and exim will NOT do any rewriting unless you tell
them and then they only rewrite according to how you tell them to rewrite.

Why don't you tell us what you want to achieve and then we can help you
and explain to you why it is done the way we suggest.

feizhou at graffiti

Dec 16, 2005, 7:36 AM

Post #10 of 49 (2640 views)
Permalink

Re: cname expand in qmail-remote [In reply to]

Charles Cazabon wrote:
> Pawe?? Panek <pawel.panek[at]inet.pl> wrote:
>
>>In another case the mail could be delivered to bob at mainsite dot
>>com if such box exist but bob at mainsite dot com is different person than
>>bob at departmet1 dot com.
>
>
> Impossible. Repeat: since "department1.com" is a CNAME for "mainsite.com",
> they /cannot/ be different people, as <bob[at]department1.com> and
> <bob[at]mainsite.com> are /the same address written different ways/.
>
> Charles

Have you forgotten virtual domains?

pawel.panek at inet

Dec 16, 2005, 7:58 AM

Post #11 of 49 (2627 views)
Permalink

Re: cname expand in qmail-remote [In reply to]

> Paweł Panek wrote:
> > hi,
> > Ok, I see you don't catch my point. I wrote one thing bad - the CNAMEs
can't
> > have MX records (RFC 1034, section 3.6.2). But for this DNS structure
(SOA
> > records are skiped):
> >
> > department1.com. CNAME mainsite.com. -- this is only one RR in this
domain
> >
> > department2.com. CNAME mainsite.com. -- this is only one RR in this
domain
> >
> > mainsite.com. A 1.2.3.4
> > mainsite.com. MX mail.mainsite.com.
> > mail A 1.2.3.5
> >
> > Question 1: is this dns structure broken?
>
> Yeah. I would make it:
>
> department1.com. IN A 1.2.3.4
> department1.com. IN MX 10 mail.department1.com.
> mail IN A 1.2.3.5
>
> repeat the above for all other domains.

You have to much redundancy and to much work if 1.2.3.4 will change to eg.
4.3.2.1

>
> mainsite.com. IN A 1.2.3.4
> mainsite.com. IN MX 10 mail.mainsite.com.
> mail IN A 1.2.3.5
>
> I take it you use bind. Have you heard of the $INCLUDE directive?
>
> > Question 2: if structure isn't broken so who will get an email addressed
to
> > bob at department1 dot com (using qmail MTA)?
> >
> > My answer for question 2 is: bob at mainsite dot com - this addres will
be
> > used in RCPT TO command. Now if you use recipient checking at smtp
session
>
> Absolute nonsense. The answer is it depends on how you configure qmail.

>
> > and bob at mainsite dot com doesn't exist the message will be rejected
by
> > 1.2.3.5. In another case the mail could be delivered to bob at mainsite
dot
> > com if such box exist but bob at mainsite dot com is different person
than
> > bob at departmet1 dot com. It is true that envelope sender and recipient
> > wont be rewritten. Rewriting has place only in RCPT TO and MAIL FROM
>
> You have no idea what you are talking about. qmail DOES NOT rewrite
period.

Oh yes it does. qmail-remote.c lines 300-308 (what for is addrmangle
function?)

>
> > commands. I use recipient checking against MySQL database at smtp
session.
> > All mail boxes are defined in MySQL database. When qmail is delivering
> > message it doesn't obey envelope recipient, its using recipient from
RCPT TO
> > command and this is right but RCPT TO command is bad.
>
> You have no idea what you are talking about.
>
> > Is my thinking broken or cname rewritnig in qmail is broken? Please
check if
> > some other MTAs (Postfix, Exim) are making this rewriting.
>
> Like I said, postfix and exim will NOT do any rewriting unless you tell
> them and then they only rewrite according to how you tell them to rewrite.

I write this once again: I'm not talking about rewriting envelope sender or
recipient. I'm talking about rewritting domains used to MAIL FROM and RCPT
TO commands.

>
> Why don't you tell us what you want to achieve and then we can help you
> and explain to you why it is done the way we suggest.
>

pawel.panek at inet

Dec 16, 2005, 8:01 AM

Post #12 of 49 (2634 views)
Permalink

Re: cname expand in qmail-remote [In reply to]

hi,
Now real life example. Plese check domain lifecore.pl. It is cname for
integris-medical.pl. Domain integris-medical.pl has an A, MX and NS records.
Using qmail-inject please try to deliver a message to info at lifecore.pl.
You will get bounce that mail.inet.pl doesn't like recipient. But info at
lifecore.pl exist. It is so because qmai-inject has passed message to
qmail-remote and it used domain integris-medical.pl in RCPT TO command and
info at integirs-medical.pl doesn't exist. Now try do the same using
sendmail from Exim package, be sure that this sendmail isn't symbolic link
to qmail-inject.
PS
Thank You all for your answers. I really appreciate this.
----- Original Message -----
From: "Charles Cazabon" <qmail[at]discworld.dyndns.org>
To: <qmail[at]list.cr.yp.to>
Sent: Friday, December 16, 2005 4:29 PM
Subject: Re: cname expand in qmail-remote

> Pawe?? Panek <pawel.panek[at]inet.pl> wrote:
> > In another case the mail could be delivered to bob at mainsite dot
> > com if such box exist but bob at mainsite dot com is different person
than
> > bob at departmet1 dot com.
>
> Impossible. Repeat: since "department1.com" is a CNAME for
"mainsite.com",
> they /cannot/ be different people, as <bob[at]department1.com> and
> <bob[at]mainsite.com> are /the same address written different ways/.
>
> Charles
> --
> --------------------------------------------------------------------------
> Charles Cazabon <qmail[at]discworld.dyndns.org>
> Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
> My services include qmail consulting. See http://pyropus.ca/ for details.
> --------------------------------------------------------------------------
>

kyle-qmail at memoryhole

Dec 16, 2005, 8:21 AM

Post #13 of 49 (2633 views)
Permalink

Re: cname expand in qmail-remote [In reply to]

On Friday, December 16 at 04:18 PM, quoth Paweł Panek:
> for this DNS structure (SOA records are skiped):
>
> department1.com. CNAME mainsite.com. -- this is only one RR in this domain
>
> department2.com. CNAME mainsite.com. -- this is only one RR in this domain
>
> mainsite.com. A 1.2.3.4
> mainsite.com. MX mail.mainsite.com.
> mail A 1.2.3.5
>
> Question 1: is this dns structure broken?

Nope.

> Question 2: if structure isn't broken so who will get an email addressed to
> bob at department1 dot com (using qmail MTA)?

Let's translate that into something more concrete: If a message with an
RCPT TO: bob at department1 dot com is relayed by a qmail server, where
will it go?

The answer is: qmail will contact 1.2.3.5 and send the mail RCPT TO: bob
at departmen1 dot com.

> My answer for question 2 is: bob at mainsite dot com - this addres
> will be used in RCPT TO command.

That is incorrect. Qmail does not change the RCPT TO address (nor does
any other standard MTA). You can, of course, run the mail through some
sort of filter to mangle it (and other MTAs allow you to do this within
their own config files), but the standard is not to mangle the RCPT TO
address.

> It is true that envelope sender and recipient wont be rewritten.
> Rewriting has place only in RCPT TO and MAIL FROM commands.

Um, the envelope sender IS the MAIL FROM address, and the envelope
recipient IS the RCPT TO address.

> I use recipient checking against MySQL database at smtp session. All
> mail boxes are defined in MySQL database. When qmail is delivering
> message it doesn't obey envelope recipient, its using recipient from
> RCPT TO command and this is right but RCPT TO command is bad. Is my
> thinking broken or cname rewritnig in qmail is broken?

If that's what your qmail is doing, then one of the patches you added to
it is broken.

> Please check if some other MTAs (Postfix, Exim) are making this
> rewriting.

By default, they are not.

~Kyle
--
The sacred rights of mankind are not to be rummaged for, among old
parchments, or musty records. They are written, as with a sun beam in
the whole volume of human nature, by the hand of the divinity itself;
and can never be erased or obscured by mortal power.
-- Alexander Hamilton, 1775

qmail at discworld

Dec 16, 2005, 8:26 AM

Post #14 of 49 (2637 views)
Permalink

Re: cname expand in qmail-remote [In reply to]

Feizhou <feizhou[at]graffiti.net> wrote:
> >
> > Impossible. Repeat: since "department1.com" is a CNAME for
> > "mainsite.com", they /cannot/ be different people, as
> > <bob[at]department1.com> and <bob[at]mainsite.com> are /the same address written
> > different ways/.
>
> Have you forgotten virtual domains?

No, I haven't forgotten them -- but they're irrelevant to this "problem".

Repeat after me: when A is a CNAME that points to B, <addr[at]A> *is the same
address* as <addr[at]B>. You don't seem to have grasped this fundamental fact
yet, and it is the entire cause of your misunderstanding of qmail's behaviour
in this respect.

Charles
--
--------------------------------------------------------------------------
Charles Cazabon <qmail[at]discworld.dyndns.org>
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
My services include qmail consulting. See http://pyropus.ca/ for details.
--------------------------------------------------------------------------

feizhou at graffiti

Dec 16, 2005, 8:35 AM

Post #15 of 49 (2640 views)
Permalink

Re: cname expand in qmail-remote [In reply to]

Charles Cazabon wrote:
> Feizhou <feizhou[at]graffiti.net> wrote:
>
>>>Impossible. Repeat: since "department1.com" is a CNAME for
>>>"mainsite.com", they /cannot/ be different people, as
>>><bob[at]department1.com> and <bob[at]mainsite.com> are /the same address written
>>>different ways/.
>>
>>Have you forgotten virtual domains?
>
>
> No, I haven't forgotten them -- but they're irrelevant to this "problem".
>
> Repeat after me: when A is a CNAME that points to B, <addr[at]A> *is the same
> address* as <addr[at]B>. You don't seem to have grasped this fundamental fact
> yet, and it is the entire cause of your misunderstanding of qmail's behaviour
> in this respect.

Ok. dns rules say: when A is a CNAME that points to B, then both are the
same entity hence the term alias. No problem.

So Pawel really needs to learn how to use $INCLUDE if he is using bind
and create separate domain entities. Gotcha.

feizhou at graffiti

Dec 16, 2005, 8:45 AM

Post #16 of 49 (2639 views)
Permalink

Re: cname expand in qmail-remote [In reply to]

> You have to much redundancy and to much work if 1.2.3.4 will change to eg.
> 4.3.2.1

You missed a question and a point.
>
>
>>mainsite.com. IN A 1.2.3.4
>>mainsite.com. IN MX 10 mail.mainsite.com.
>>mail IN A 1.2.3.5
>>
>>I take it you use bind. Have you heard of the $INCLUDE directive?

Right here. *I* ran dns servers hosting hundred of domains where a set
of domains' MX would point to a set of servers.

I don't go making X * Y number of changes for X number of domains. I
make Y number of server changes and then I am done.

Here is a clue. $INCLUDE directive if you are using bind.

qmail at discworld

Dec 16, 2005, 8:52 AM

Post #17 of 49 (2638 views)
Permalink

Re: cname expand in qmail-remote [In reply to]

Kyle Wheeler <kyle-qmail[at]memoryhole.net> wrote:
> >
> >department1.com. CNAME mainsite.com.
[...]
> >mainsite.com. MX mail.mainsite.com.
> >mail A 1.2.3.5

> Let's translate that into something more concrete: If a message with an
> RCPT TO: bob at department1 dot com is relayed by a qmail server, where
> will it go?
>
> The answer is: qmail will contact 1.2.3.5 and send the mail RCPT TO: bob
> at departmen1 dot com.

Uh - no it won't. qmail will connect to 1.2.3.5 and use <bob[at]mainsite.com> as
the envelope recipient address.

> That is incorrect. Qmail does not change the RCPT TO address

Sure it does, in this case.

> (nor does any other standard MTA).

All conformant MTAs do this with CNAMEs.

Charles
--
--------------------------------------------------------------------------
Charles Cazabon <qmail[at]discworld.dyndns.org>
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
My services include qmail consulting. See http://pyropus.ca/ for details.
--------------------------------------------------------------------------

feizhou at graffiti

Dec 16, 2005, 8:58 AM

Post #18 of 49 (2638 views)
Permalink

Re: cname expand in qmail-remote [In reply to]

Pawel Panek wrote:
> hi,
> Now real life example. Plese check domain lifecore.pl. It is cname for
> integris-medical.pl. Domain integris-medical.pl has an A, MX and NS records.
> Using qmail-inject please try to deliver a message to info at lifecore.pl.
> You will get bounce that mail.inet.pl doesn't like recipient. But info at
> lifecore.pl exist. It is so because qmai-inject has passed message to
> qmail-remote and it used domain integris-medical.pl in RCPT TO command and
> info at integirs-medical.pl doesn't exist. Now try do the same using
> sendmail from Exim package, be sure that this sendmail isn't symbolic link
> to qmail-inject.

Let's see:

/var/qmail/bin/qmail-inject -ffeizhouatgraffiti.net infoatlifecore.pl
type mail content.
ctrl-d

No bounce.

@4000000043a2eb452d421134 info msg 156: bytes 286 from
<feizhouatgraffiti.net> qp 23628 uid 1001
@4000000043a2eb452d72c9dc starting delivery 393928: msg 156 to remote
infoatlifecore.pl
@4000000043a2eb480db4b86c delivery 393928: success:
80.72.192.35_accepted_message./Remote_host_said:_250_ok_1134750524_qp_1
2007/

What gives?

fines at macalester

Dec 16, 2005, 9:24 AM

Post #19 of 49 (2645 views)
Permalink

Re: cname expand in qmail-remote [In reply to]

--- Original Message ---
> hi,
> Now real life example. Plese check domain lifecore.pl. It is
> cname for
> integris-medical.pl. Domain integris-medical.pl has an A, MX
> and NS records.
> Using qmail-inject please try to deliver a message to info at
> lifecore.pl.
> You will get bounce that mail.inet.pl doesn't like recipient.
> But info at
> lifecore.pl exist. It is so because qmai-inject has passed
> message to
> qmail-remote and it used domain integris-medical.pl in RCPT
> TO command and
> info at integirs-medical.pl doesn't exist.

No. You are having difficulty with DNS, not with qmail. Look at the results from "dig mx lifecore.pl":

;; QUESTION SECTION:
;lifecore.pl. IN MX

;; ANSWER SECTION:
lifecore.pl. 85706 IN CNAME integris-medical.pl.
integris-medical.pl. 85706 IN MX 5 mail.inet.pl.

The question asked, in english, is "What is the mail exchanger (MX) for the 'lifecore.pl' domain?"

The answer, in english, is "I looked up lifecore.pl, which is just a CNAME (common name) for integris-medical.pl. This tells me that lifecore.pl is just another name for integris-medical.pl. This isn't the answer I need (an MX record), so I then had to lookup the MX record for integris-medical.pl, and got an answer, mail.inet.pl. The mail exchanger for lifecore.pl (aka integris-medical.pl) is mail.inet.pl."

The result, in english is "Since lifecore.pl is just a CNAME (aka 'alias' or 'nickname') for integris-medical.pl, I will address the envelope of the email to 'info[at]integris-medical.pl, and then send the message to MX of record, 'mail.inet.pl' for delivery."

This is all DNS, and your misunderstanding of how it is working is causing your confusion.

As someone suggested several messages back, you should post the question in terms of what you are trying to do.

Ted

kyle-qmail at memoryhole

Dec 16, 2005, 10:34 AM

Post #20 of 49 (2632 views)
Permalink

Re: cname expand in qmail-remote [In reply to]

On Friday, December 16 at 10:52 AM, quoth Charles Cazabon:
>> Let's translate that into something more concrete: If a message with
>> an RCPT TO: bob at department1 dot com is relayed by a qmail server,
>> where will it go?
>>
>> The answer is: qmail will contact 1.2.3.5 and send the mail RCPT TO: bob
>> at departmen1 dot com.
>
>Uh - no it won't. qmail will connect to 1.2.3.5 and use <bob[at]mainsite.com> as
>the envelope recipient address.
>
>> That is incorrect. Qmail does not change the RCPT TO address
>
>Sure it does, in this case.
>
>> (nor does any other standard MTA).
>
>All conformant MTAs do this with CNAMEs.

What?

So, if your domain is pyropus.ca, and let's pretend pyropus.ca is a
CNAME for sharedhosting.com. I send an email like this:

echo test | qmail-inject charles[at]pyropus.ca

You're telling me that my qmail server is gonna contact
sharedhosting.com and say:

MAIL FROM: <kyle-qmail[at]memoryhole.net>
RCPT TO: <charles[at]sharedhosting.com>

???

I don't believe you, that doesn't make any sense to me. What's to stop
J-random domain from setting up mail aliases for me without my
permission then? If you set up pyropus.ca to be a CNAME for
memoryhole.net, and I do:

echo test | qmail-inject kyle-qmail[at]pyropus.ca

I'm *not* going to receive that test message in any form other than a
bounce message.

~Kyle
--
Come to me, son of Jor-El. Kneel before Zod. Snootchie-bootchies.
-- Jay

qmail at discworld

Dec 16, 2005, 11:02 AM

Post #21 of 49 (2637 views)
Permalink

Re: cname expand in qmail-remote [In reply to]

Kyle Wheeler <kyle-qmail[at]memoryhole.net> wrote:
> >
> > > That is incorrect. Qmail does not change the RCPT TO address
> >
> > Sure it does, in this case.
> >
> > > (nor does any other standard MTA).
> >
> > All conformant MTAs do this with CNAMEs.
>
> What?
>
> So, if your domain is pyropus.ca, and let's pretend pyropus.ca is a
> CNAME for sharedhosting.com. I send an email like this:
>
> echo test | qmail-inject charles[at]pyropus.ca
>
> You're telling me that my qmail server is gonna contact
> sharedhosting.com and say:
>
> MAIL FROM: <kyle-qmail[at]memoryhole.net>
> RCPT TO: <charles[at]sharedhosting.com>
>
> ???

Yes.

> I don't believe you, that doesn't make any sense to me.

Go ahead and try it. You'll see it does. qmail (as well as other conformant
MTAs) rewrites envelope addresses containing CNAMEs, as required by the RFCs.
Note that qmail does /not/ rewrite the message header, just the envelope.

Charles
--
--------------------------------------------------------------------------
Charles Cazabon <qmail[at]discworld.dyndns.org>
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
My services include qmail consulting. See http://pyropus.ca/ for details.
--------------------------------------------------------------------------

fines at macalester

Dec 16, 2005, 11:34 AM

Post #22 of 49 (2639 views)
Permalink

Re: cname expand in qmail-remote [In reply to]

--- Original Message ---
> On Friday, December 16 at 10:52 AM, quoth Charles Cazabon:
> >> Let's translate that into something more concrete: If a message with
> >> an RCPT TO: bob at department1 dot com is relayed by a qmail server,
> >> where will it go?
> >>
> >> The answer is: qmail will contact 1.2.3.5 and send the mail RCPT TO: bob
> >> at departmen1 dot com.
> >
> >Uh - no it won't. qmail will connect to 1.2.3.5 and use <bob[at]mainsite.com> as
> >the envelope recipient address.
> >
> >> That is incorrect. Qmail does not change the RCPT TO address
> >
> >Sure it does, in this case.
> >
> >> (nor does any other standard MTA).
> >
> >All conformant MTAs do this with CNAMEs.
>
> What?
>
> So, if your domain is pyropus.ca, and let's pretend pyropus.ca
> is a
> CNAME for sharedhosting.com. I send an email like this:
>
> echo test | qmail-inject charles[at]pyropus.ca
>
> You're telling me that my qmail server is gonna contact
> sharedhosting.com and say:
>
> MAIL FROM: <kyle-qmail[at]memoryhole.net>
> RCPT TO: <charles[at]sharedhosting.com>
>
> ???
>
> I don't believe you, that doesn't make any sense to me. What's
> to stop
> J-random domain from setting up mail aliases for me without
> my
> permission then? If you set up pyropus.ca to be a CNAME for
> memoryhole.net, and I do:
>
> echo test | qmail-inject kyle-qmail[at]pyropus.ca
>
> I'm *not* going to receive that test message in any form other
> than a
> bounce message.

The address is undeniably getting rewritten. Sending a message through qmail using a client like Thunderbird, or from the command line with "echo "to: info[at]lifecore.pl" | qmail-inject", it happens. See the tcp dump packet trace I took while sending a message using either method here:
http://www.apecity.com/lifecore.dmp

You may view it with "tcpdump -A -r lifecore.dmp" or using Ethereal, etc. See packet #10.

To address your DNS question, the problem you propose is not a problem because you would have to be retarded to do it unless you wanted to for a specific reason.

In MY dns server, I could add records like:
$ORIGIN mydomain.com.
myhost IN MX 10 smtp.yourhost.com.

This would mean any mail coming to me would go to your server, which would certainly bounce it and I'd never get any mail. Now why would I want to do that? We do have a case where we do want to do that. We want our alumni to have permanent @alumni.macalester.edu email accounts, but we don't want to manage those users and don't want to have to process all of those messages. So we have this MX record:
alumni IN MX 10 smtp.publishingconcepts.com.

...which just sends anything for @alumni.macalester.edu addresses to the company we've contracted with.

On our DNS server I added a test record of this:
$ORIGIN macalester.edu.
example IN CNAME apecity.com.

This causes "dig mx example.macalester.edu" to return:
;; ANSWER SECTION:
example.macalester.edu. 10800 IN CNAME apecity.com.
apecity.com. 2760 IN MX 10 mailcluster.globat.com.

I then sent an email to "ape[at]example.macalester.edu".

See http://www.apecity.com/example_apecity.dmp for the results. You don't have to believe or not believe, you just need tcpdump. :)

Ted

>
> ~Kyle
> --
> Come to me, son of Jor-El. Kneel before Zod. Snootchie-bootchies.
>
> -- Jay
>

pawel.panek at inet

Dec 17, 2005, 9:26 AM

Post #23 of 49 (2635 views)
Permalink

Re: cname expand in qmail-remote [In reply to]

> Let's see:
>
> /var/qmail/bin/qmail-inject -ffeizhouatgraffiti.net infoatlifecore.pl
> type mail content.
> ctrl-d
>
> No bounce.
>
> @4000000043a2eb452d421134 info msg 156: bytes 286 from
> <feizhouatgraffiti.net> qp 23628 uid 1001
> @4000000043a2eb452d72c9dc starting delivery 393928: msg 156 to remote
> infoatlifecore.pl
> @4000000043a2eb480db4b86c delivery 393928: success:
> 80.72.192.35_accepted_message./Remote_host_said:_250_ok_1134750524_qp_1
> 2007/
>
> What gives?
>
Thank you for your test. Yes, it worked. I saw yours message:
--------------------------------------------
Return-Path: <feizhou at graffiti.net>
Delivered-To: info at lifecore.pl
Received: (qmail 12012 invoked from network); 16 Dec 2005 16:28:44 -0000
Received: from unknown (HELO pop5-1.us4.outblaze.com) (205.158.62.125)
by mail.inet.pl with SMTP; 16 Dec 2005 16:28:44 -0000
Received: (qmail 23628 invoked by uid 1001); 16 Dec 2005 16:28:38 -0000
Date: 16 Dec 2005 16:27:55 -0000
Message-ID: <20051216162755.22917.qmail at pop5-1.us4.outblaze.com>
From: "Feizhou" <feizhou at graffiti.net>
To: "You" <info at lifecore.pl>
Subject: Testing claims of qmail-remote

Hello.
--------------------------------------------
It pointed me that rewriting isn't performed when RELAYCLIENT enviroment
variable is set. I've looked more careful into source of qmail-remote I've
found that addrmangle function depends on relayclient variable. If everybody
will use auth or another way of setting RELAYCLIENT, I'll never start this
discussion. But in some cases eg. webmail is using only
qmail-inject->qmail-remote chain without setting RELAYCLIENT and then comes
rewritnig. Please use clean enviroment and be sure that you don't set this
variable - you'll get bounce.
Regs,
-- Pawel

pawel.panek at inet

Dec 17, 2005, 10:24 AM

Post #24 of 49 (2626 views)
Permalink

Re: cname expand in qmail-remote [In reply to]

> Go ahead and try it. You'll see it does. qmail (as well as other
conformant
> MTAs) rewrites envelope addresses containing CNAMEs, as required by the
RFCs.

I found that rfc 1034 section 3.6.2 explicit says that a at A and a at B
when A is CNAME for B goes to same mailbox. But I think this doesn't
authorize MTA to make rewrite in RCPT TO command. After recieving message
with unchanged envelope recipient the local delivery process should obey
this rule and make deliveries to a at A and a at B to the same mailbox. So
problem should be solved in local delivery process not in transport process.
This rfc 1034 is form y. 1982 - pretty old paper and qmail is pretty old
program too. I think rfc 1034 should be revised - mybe this 3.6.2 section is
now obsolete in some parts but I didn't find any information about that.
DNS service can not decide which mail address is an alias and which is real
one. Only the mail accounts managment system can make this decision. DNS
should only do its job - find addresses. DNS can only point us to host which
will take care of our request but how this request will be served depends
only on service to which the request is pointed. On this basis mail accounts
managment system can treat a at A and a at B as different addresses
eventhough A is CNAME for B.
You can say that Exim and Postfix are nonconformant to RFCs but in this case
their behaviour (not to rewrite) is right. World is changing and RFCs should
change to.

> Note that qmail does /not/ rewrite the message header, just the envelope.

It is correct. I want to appologize for my language mistakes - when I was
writting 'envelope' I meant 'headers' - realy sory for that. My english
isn't good.

--Pawel
>
> Charles
> --
> --------------------------------------------------------------------------
> Charles Cazabon <qmail[at]discworld.dyndns.org>
> Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
> My services include qmail consulting. See http://pyropus.ca/ for details.
> --------------------------------------------------------------------------
>

qmail at discworld

Dec 18, 2005, 1:32 PM

Post #25 of 49 (2626 views)
Permalink

Re: cname expand in qmail-remote [In reply to]

Pawel Panek <pawel.panek[at]inet.pl> wrote:
> > Go ahead and try it. You'll see it does. qmail (as well as other
> > conformant
> > MTAs) rewrites envelope addresses containing CNAMEs, as required by the
> > RFCs.
>
> I found that rfc 1034 section 3.6.2 explicit says that a at A and a at B
> when A is CNAME for B goes to same mailbox.

RFC821 also said this in section 3.7 on domains:

Whenever domain names are used in SMTP only the official names are used, the
use of nicknames or aliases is not allowed.

A CNAME is a client-side DNS alias. RFC 821 forbade the use of such aliases.

Charles
--
--------------------------------------------------------------------------
Charles Cazabon <qmail[at]discworld.dyndns.org>
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
My services include qmail consulting. See http://pyropus.ca/ for details.
--------------------------------------------------------------------------

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com