seeking: Ian Jackson - Debian

This is a discussion on seeking: Ian Jackson - Debian ; iwj@d.o expands to a greenend.org.uk address, and the mx for that domain refuses to accept my mail. : host mx-relay.chiark.greenend.org.uk[212.13.197.229] said: 550 invalid MAIL-FROM: Error during DNS MX lookup for lapse.madduck.net: DNS alias found where canonical name wanted [Irritated] (in ...

+ Reply to Thread
Results 1 to 19 of 19

Thread: seeking: Ian Jackson

  1. seeking: Ian Jackson

    iwj@d.o expands to a greenend.org.uk address, and the mx for that
    domain refuses to accept my mail.

    : host
    mx-relay.chiark.greenend.org.uk[212.13.197.229] said: 550
    invalid MAIL-FROM: Error during DNS MX lookup for
    lapse.madduck.net: DNS alias found where canonical name wanted
    [Irritated] (in reply to RCPT TO command)

    Yes, lapse.madduck.net is a CNAME (*c*anonical *name*) to an MX RR,
    and that's RFC-compliant ttbomk. If it is not, I would appreciate if
    someone shoved the relevant sections into my face.

    In the mean time, I'd be grateful if Ian gave me a means to
    communicate with him. Or if someone would offer to relay a message
    to him.

    The spammers have long won if people put such boulders in the way of
    communication. Oh wait, I doubt spammers use CNAMEs...

    --
    .''`. martin f. krafft
    : :' : proud Debian developer, author, administrator, and user
    `. `'` http://people.debian.org/~madduck - http://debiansystem.info
    `- Debian - when you have better things to do than fixing systems

    "although occasionally there is something to be said for solitude."
    -- special agent dale cooper

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFHC8pAIgvIgzMMSnURAl5FAKCy7YmjiFFuujp01OZZ92 j2eXHmpQCfZ4LV
    ti6R2avENZ6gQCWG1M8kVU4=
    =eJyk
    -----END PGP SIGNATURE-----


  2. mail from and CNAMEs (was: seeking: Ian Jackson)

    I don't really think we need to have this discussion on
    debian-devel. Sorry for not setting reply-to. I will not post more
    than this one reply, which I hope sets things straight.

    also sprach Simon Josefsson [2007.10.09.2015 +0100]:
    > RFC 1034 section 3.6.2:
    >
    > Domain names in RRs which point at another name should always
    > point at the primary name and not the alias. This avoids extra
    > indirections in accessing information.


    I read that as: CNAMEs should not point at other CNAMEs, and MX/NS
    RRs should point at A records, not CNAMEs. Not that an email
    address' domain cannot be a CNAME (to an MX RR, which links to two
    A RRs).

    > See also RFC 1912 section 2.4:
    >
    > Don't use CNAMEs in combination with RRs which point to other names
    > like MX, CNAME, PTR and NS. (PTR is an exception if you want to
    > implement classless in-addr delegation.) For example, this is
    > strongly discouraged:
    >
    > podunk.xx. IN MX mailhost
    > mailhost IN CNAME mary
    > mary IN A 1.2.3.4


    I don't do that.

    lapse.madduck.net is an alias for rw.madduck.net.
    rw.madduck.net mail is handled by 99 b.mx.madduck.net.
    rw.madduck.net mail is handled by 10 a.mx.madduck.net.

    What they say is that it should not be

    lapse.madduck.net is an alias for rw.madduck.net.
    lapse.madduck.net mail is handled by 99 b.mx.madduck.net.
    lapse.madduck.net mail is handled by 10 a.mx.madduck.net.
    ^^^^^
    which makes perfect sense since it would be impossible to decide
    which MX to use if rw.madduck.net also had MX RRs.

    > [RFC 1034] in section 3.6.2 says this should not be done, and [RFC
    > 974] explicitly states that MX records shall not point to an alias
    > defined by a CNAME.


    I don't do either.

    --
    .''`. martin f. krafft
    : :' : proud Debian developer, author, administrator, and user
    `. `'` http://people.debian.org/~madduck - http://debiansystem.info
    `- Debian - when you have better things to do than fixing systems

    "africa is a nation..."
    - george w. bush

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFHC9iSIgvIgzMMSnURAm43AJ9MSYgnF1VSypcbv0h8On j4B6APRQCgyl/3
    BeTPHXTcoLlvbatpsIEDRpQ=
    =PSCp
    -----END PGP SIGNATURE-----


  3. Re: seeking: Ian Jackson

    martin f krafft writes:

    > iwj@d.o expands to a greenend.org.uk address, and the mx for that
    > domain refuses to accept my mail.
    >
    > : host
    > mx-relay.chiark.greenend.org.uk[212.13.197.229] said: 550
    > invalid MAIL-FROM: Error during DNS MX lookup for
    > lapse.madduck.net: DNS alias found where canonical name wanted
    > [Irritated] (in reply to RCPT TO command)
    >
    > Yes, lapse.madduck.net is a CNAME (*c*anonical *name*) to an MX RR,
    > and that's RFC-compliant ttbomk. If it is not, I would appreciate if
    > someone shoved the relevant sections into my face.


    RFC 1034 section 3.6.2:

    Domain names in RRs which point at another name should always point at
    the primary name and not the alias. This avoids extra indirections in
    accessing information.

    See also RFC 1912 section 2.4:

    Don't use CNAMEs in combination with RRs which point to other names
    like MX, CNAME, PTR and NS. (PTR is an exception if you want to
    implement classless in-addr delegation.) For example, this is
    strongly discouraged:

    podunk.xx. IN MX mailhost
    mailhost IN CNAME mary
    mary IN A 1.2.3.4


    [RFC 1034] in section 3.6.2 says this should not be done, and [RFC
    974] explicitly states that MX records shall not point to an alias
    defined by a CNAME. This results in unnecessary indirection in
    accessing the data, and DNS resolvers and servers need to work more
    to get the answer. If you really want to do this, you can accomplish
    the same thing by using a preprocessor such as m4 on your host files.

    There is some disagreement though:

    http://www.mengwong.com/misc/rfc1912-is-wrong.html

    /Simon


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  4. Re: seeking: Ian Jackson

    Hi,

    On Tue Oct 09, 2007 at 19:36:49 +0100, martin f krafft wrote:
    > iwj@d.o expands to a greenend.org.uk address, and the mx for that
    > domain refuses to accept my mail.
    >
    > : host
    > mx-relay.chiark.greenend.org.uk[212.13.197.229] said: 550
    > invalid MAIL-FROM: Error during DNS MX lookup for
    > lapse.madduck.net: DNS alias found where canonical name wanted
    > [Irritated] (in reply to RCPT TO command)
    >
    > Yes, lapse.madduck.net is a CNAME (*c*anonical *name*) to an MX RR,
    > and that's RFC-compliant ttbomk. If it is not, I would appreciate if
    > someone shoved the relevant sections into my face.
    >
    > In the mean time, I'd be grateful if Ian gave me a means to
    > communicate with him. Or if someone would offer to relay a message
    > to him.
    >
    > The spammers have long won if people put such boulders in the way of
    > communication. Oh wait, I doubt spammers use CNAMEs...


    how about sending mails from master.debian.org with either
    madduck@debian.org or madduck@master.debian.org?

    Greetings
    Martin

    PS: i know, that solution is too simple...
    --
    [root@debian /root]# man real-life
    No manual entry for real-life


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  5. Re: seeking: Ian Jackson

    also sprach Martin Zobel-Helas [2007.10.09.2026 +0100]:
    > how about sending mails from master.debian.org with either
    > madduck@debian.org or madduck@master.debian.org?


    I couldn't sign those messages. But I could temporarily set mutt's
    $envelope_from_address. Thanks for the hint.

    --
    .''`. martin f. krafft
    : :' : proud Debian developer, author, administrator, and user
    `. `'` http://people.debian.org/~madduck - http://debiansystem.info
    `- Debian - when you have better things to do than fixing systems

    "the human brain is like an enormous fish --
    it is flat and slimy
    and has gills through which it can see."
    -- monty python

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFHC+BWIgvIgzMMSnURAqi1AKDKCYAMffpjGSFEmVSctD vgfNOsrACg14d6
    lYYojr4+Cq1qQoG8yty7kCY=
    =YoTK
    -----END PGP SIGNATURE-----


  6. Re: seeking: Ian Jackson

    martin f krafft writes ("seeking: Ian Jackson"):
    > In the mean time, I'd be grateful if Ian gave me a means to
    > communicate with him. Or if someone would offer to relay a message
    > to him.


    A few people have drawn my attention to this thread, thanks. For
    future reference, my db.debian.org entry ought to have my phone number
    in it and I think it's fine to use that when email fails.

    I've added a hole in my filter for *.madduck.net so martin should be
    able to email me now.


    > Yes, lapse.madduck.net is a CNAME (*c*anonical *name*) to an MX RR,
    > and that's RFC-compliant ttbomk. If it is not, I would appreciate if
    > someone shoved the relevant sections into my face.


    The prevailing IETF standard for mail transmission over the Internet
    is STD-10 (RFC821), which says:

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

    "CNAME" in CNAME RR means "the lhs domain is an alias; the canonical
    name is as follows". So
    lapse.madduck.net. CNAME rw.madduck.net.
    means
    "lapse.madduck.net's canonical name is rw.madduck.net"
    ie that lapse.madduck.net is _not_ a canonical name but an alias.

    RFC2181 is helpful on this point:

    10.1.1. CNAME terminology

    It has been traditional to refer to the label of a CNAME record as "a
    CNAME". This is unfortunate, as "CNAME" is an abbreviation of
    "canonical name", and the label of a CNAME record is most certainly
    not a canonical name. It is, however, an entrenched usage. Care
    must therefore be taken to be very clear whether the label, or the
    value (the canonical name) of a CNAME resource record is intended.
    In this document, the label of a CNAME resource record will always be
    referred to as an alias.

    If you have a suggestion for improving the error message I'd be happy
    to hear it - but preferably not anything much longer than the existing
    message "DNS alias found where canonical name wanted" which is already
    rather on the long side.

    > The spammers have long won if people put such boulders in the way of
    > communication. Oh wait, I doubt spammers use CNAMEs...


    Statistics for this cause of rejection for last week:

    -chiark:~> grep 'DNS alias found where canonical name wanted' /var/log/sauce/reject.log.0 | wc -l
    19893
    -chiark:~>

    This includes attempts which would also have been rejected for some
    other reason, but it gives an idea of the prevalence.

    And yes, I'm afraid I agree with you - the spammers have indeed won.
    I regret the inconvenience.

    Regards,
    Ian.


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  7. RFC 2?821 and CNAMEs (was: seeking: Ian Jackson)

    Thanks, Ian, for your reply. I don't quite agree with it though.

    also sprach Ian Jackson [2007.10.09.2102 +0100]:
    > The prevailing IETF standard for mail transmission over the Internet
    > is STD-10 (RFC821), which says:


    RFC 2821 obsoletes STD-10, and says:

    3.6 Domains

    Only resolvable, fully-qualified, domain names (FQDNs) are permitted
    when domain names are used in SMTP. In other words, names that can
    be resolved to MX RRs or A RRs (as discussed in section 5) are
    permitted, as are CNAME RRs whose targets can be resolved, in turn,
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^
    to MX or A RRs.
    ^^^^^^^^^^^^^^^

    Though I guess it gets interesting when we start to look at the
    meaning of "obsoletes":

    Abstract

    This document is a self-contained specification of the basic protocol
    for the Internet electronic mail transport. It consolidates, updates
    and clarifies, but doesn't add new or change existing functionality
    of the following: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    - the original SMTP (Simple Mail Transfer Protocol) specification of
    RFC 821 [30],

    yes, one could argue.

    > RFC2181 is helpful on this point:
    >
    > 10.1.1. CNAME terminology


    This is interesting for I really always thought it was the other way
    around. Now I have to adjust the way I use that word in day to day
    parlance.

    > And yes, I'm afraid I agree with you - the spammers have indeed won.
    > I regret the inconvenience.


    No problem; I appreciate your time and the hole you punched for me.

    --
    .''`. martin f. krafft
    : :' : proud Debian developer, author, administrator, and user
    `. `'` http://people.debian.org/~madduck - http://debiansystem.info
    `- Debian - when you have better things to do than fixing systems

    "heuristic is computer science jargon for 'doesn't actually work.'"
    -- charlie reiman

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFHC+hnIgvIgzMMSnURArVIAKDbGmERLhWMUrsTQ1i1NM s4fCqMKACfaa/f
    EmE57y4fCxyaKUysdxzaFaE=
    =X0rF
    -----END PGP SIGNATURE-----


  8. Re: RFC 2?821 and CNAMEs

    martin f krafft writes:

    > RFC 2821 obsoletes STD-10, and says:


    > 3.6 Domains


    > Only resolvable, fully-qualified, domain names (FQDNs) are permitted
    > when domain names are used in SMTP. In other words, names that can
    > be resolved to MX RRs or A RRs (as discussed in section 5) are
    > permitted, as are CNAME RRs whose targets can be resolved, in turn,
    > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^
    > to MX or A RRs.
    > ^^^^^^^^^^^^^^^


    > Though I guess it gets interesting when we start to look at the
    > meaning of "obsoletes":


    As someone who was on the RFC 2821 working group and vaguely remembers
    this, I seem to recall that this was one of those cases where everyone was
    already doing this and it didn't cause interoperability problems, so RFC
    2821 backed off the strength of the requirement.

    Note, though, that STD-10 is a Standard whereas RFC 2821 is still only a
    Proposed Standard. IIRC, formally the obsolete only fully applies once
    RFC 2821 reaches the same level in the standards process.

    --
    Russ Allbery (rra@debian.org)


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  9. Re: RFC 2?821 and CNAMEs

    also sprach Russ Allbery [2007.10.09.2243 +0100]:
    > Note, though, that STD-10 is a Standard whereas RFC 2821 is still
    > only a Proposed Standard. IIRC, formally the obsolete only fully
    > applies once RFC 2821 reaches the same level in the standards
    > process.


    Does that mean I ought to be changing my DNS setup?

    --
    .''`. martin f. krafft
    : :' : proud Debian developer, author, administrator, and user
    `. `'` http://people.debian.org/~madduck - http://debiansystem.info
    `- Debian - when you have better things to do than fixing systems

    if you are walking on thin ice, you might as well dance!

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFHC/q0IgvIgzMMSnURAhYVAKCKUH5YUO5j1s2fy5bc+r65zatMvwCe Ou9o
    Lf2fuCEWz5Ff5ZR6tcUQ9L4=
    =JK4K
    -----END PGP SIGNATURE-----


  10. Re: RFC 2?821 and CNAMEs

    martin f krafft writes:
    > also sprach Russ Allbery [2007.10.09.2243 +0100]:


    >> Note, though, that STD-10 is a Standard whereas RFC 2821 is still
    >> only a Proposed Standard. IIRC, formally the obsolete only fully
    >> applies once RFC 2821 reaches the same level in the standards
    >> process.


    > Does that mean I ought to be changing my DNS setup?


    The only thing RFC 821 cares about is what hostnames you use in MAIL FROM
    and RCPT TO. If you can ensure that your mail setup uses the canonical
    name rather than the alias in the RHS of addresses in MAIL FROM, that will
    make the problem go away without changing your DNS.

    --
    Russ Allbery (rra@debian.org)


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  11. Re: seeking: Ian Jackson

    Hello martin,

    martin f krafft wrote:
    > also sprach Martin Zobel-Helas [2007.10.09.2026 +0100]:
    >> how about sending mails from master.debian.org with either
    >> madduck@debian.org or madduck@master.debian.org?

    >
    > I couldn't sign those messages.


    Give mutt a new sendmail:
    set sendmail="/usr/bin/ssh debian /usr/sbin/sendmail -oem -oi"

    Bye, J├Ârg.
    --
    Real programmers don't comment their code. It was hard to write,
    it should be hard to understand.


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  12. Re: RFC 2?821 and CNAMEs

    also sprach Russ Allbery [2007.10.10.0024 +0100]:
    > The only thing RFC 821 cares about is what hostnames you use in
    > MAIL FROM and RCPT TO. If you can ensure that your mail setup
    > uses the canonical name rather than the alias in the RHS of
    > addresses in MAIL FROM, that will make the problem go away without
    > changing your DNS.


    Of course I can ensure that, and that's what I had a while ago: for
    each of my road-warriors (rw.madduck.net; 19 of them; no, not all
    laptops; long story), I had a separate pair of MX RRs.

    I sought to simplify that and created rw.madduck.net with two MX RRs
    and CNAMEd the 19 domain names to that, *after* reading the RFCs and
    determining that it was okay (but reading RFC2821 as having
    obsoleted STD-010; your argument makes sense though).

    I'd much rather change my DNS than configure the 19 machines to use
    the same mail-from-domain. Thanks for this thread, which showed me
    that apparently this is what I have to do.

    I can't believe DNS (or SMTP for that matter) hasn't moved along in
    decades... at least not since people started to understand that data
    redundancy (not caching!) is a bad thing.

    Sorry for the noise on d-devel.

    --
    .''`. martin f. krafft
    : :' : proud Debian developer, author, administrator, and user
    `. `'` http://people.debian.org/~madduck - http://debiansystem.info
    `- Debian - when you have better things to do than fixing systems

    "the only difference between the saint and the sinner
    is that every saint has a past and every sinner has a future."
    -- oscar wilde

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFHDCrYIgvIgzMMSnURAlhoAKDsQtN4OFXhUaoC3Q0jt9 pTMRV5KACg3Es4
    JiS+slCB74tyf/YZMGcmLN4=
    =qrar
    -----END PGP SIGNATURE-----


  13. Re: RFC 2?821 and CNAMEs

    martin f krafft writes:

    > I can't believe DNS (or SMTP for that matter) hasn't moved along in
    > decades... at least not since people started to understand that data
    > redundancy (not caching!) is a bad thing.


    Yeah, both DNS and SMTP basically froze in stone a while back, and except
    for the stuff that can be done with new RRs in DNS or extensions in SMTP,
    really nothing changes. Too much code out there that will break if any
    little thing is different. There are advantages to having a mature
    standard, but it means that we get to live with all the mistakes and
    marginal decisions forever and one ends up just memorizing them.

    This is particularly bad in the area of SMTP because it's hard enough to
    write a fully compliant to every last detail SMTP agent that it's a great
    way of catching spamware, which is often written by incompetent
    programmers or in a huge hurry. So it's become quite popular to enforce
    every little detail of the SMTP standard, no matter how obscure, because
    the main Unix MTAs follow the standard in great detail and every new thing
    that you can find rejects a bunch of spam.

    For example, Stanford University rejects 80% (!!) of our incoming mail
    just by requiring an RFC-2821-compliant HELO.

    > Sorry for the noise on d-devel.


    It's a little off-topic, but it's obscure enough stuff that affects enough
    people that I think it's nice to repeat it periodically. I end up
    answering a ton of questions like this in my day job.

    --
    Russ Allbery (rra@debian.org)


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  14. Re: RFC 2?821 and CNAMEs

    martin f krafft writes ("Re: RFC 2?821 and CNAMEs"):
    > Of course I can ensure that, and that's what I had a while ago: for
    > each of my road-warriors (rw.madduck.net; 19 of them; no, not all
    > laptops; long story), I had a separate pair of MX RRs.
    >
    > I sought to simplify that and created rw.madduck.net with two MX RRs
    > and CNAMEd the 19 domain names to that,


    You should definitely change this, not just because my strict reading
    of the state of the standards forbids it, but also because the
    behaviour of other MTAs is not always what you want.

    In particular, I have seen MTAs which would (taking your situation as
    a concrete example, and when relaying mail eg as a smarthost), after
    receiving a mail with
    RCPT TO:
    would look lapse.madduck.net in the DNS, see it's an alias, and then
    decide that the right thing to do was to send to your MX
    RCPT TO:

    (Obviously this behaviour is completely barking.)

    Ian.


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  15. Re: RFC 2?821 and CNAMEs

    also sprach Ian Jackson [2007.10.10.1059 +0100]:
    > In particular, I have seen MTAs which would (taking your situation as
    > a concrete example, and when relaying mail eg as a smarthost), after
    > receiving a mail with
    > RCPT TO:
    > would look lapse.madduck.net in the DNS, see it's an alias, and then
    > decide that the right thing to do was to send to your MX
    > RCPT TO:
    >
    > (Obviously this behaviour is completely barking.)


    Yes, I have seen those two, namely MS Exchange.

    --
    .''`. martin f. krafft
    : :' : proud Debian developer, author, administrator, and user
    `. `'` http://people.debian.org/~madduck - http://debiansystem.info
    `- Debian - when you have better things to do than fixing systems

    "zum christentum wird man nicht geboren,
    man mu▀ dazu nur krank genug sein."
    - friedrich nietzsche

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFHDKVgIgvIgzMMSnURAmpdAJ9F1T9IGdNkeoM5p9Nfi5 sn3ofuUwCfT18+
    xRaNdkUO2jXUZQazVo2dO60=
    =WxKf
    -----END PGP SIGNATURE-----


  16. Re: seeking: Ian Jackson

    RFC 1123 contains this requirement:

    5.2.2 Canonicalization: RFC-821 Section 3.1

    The domain names that a Sender-SMTP sends in MAIL and RCPT
    commands MUST have been "canonicalized," i.e., they must be
    fully-qualified principal names or domain literals, not
    nicknames or domain abbreviations. A canonicalized name either
    identifies a host directly or is an MX name; it cannot be a
    CNAME.

    This means that it's fine to use domains pointing to CNAMEs in Internet
    mail. It does not matter if RFC 821 requires canonical names in RCPT or
    MAIL arguments because it's the job of the sending to apply
    canonicalization to comply with this requirement.

    But it's generally wrong to expect that RFCs reflect what's being done
    on the Internet. Current state of affairs is that hardly anybody
    implements that rule from RFC 1123 correctly. Sendmail applies it to
    headers as well, which is simply wrong. Exim doesn't implement it at
    all. I don't know about Postfix. Some MTAs (like Ian's) enforce that
    RCPT/MAIL arguments are in fact canonical names, decreasing email
    reachability. There aren't that many MTAs which do that (and I think
    it's a questionable configuration choice), and the only reasonable way
    around that is not to use non-canonical domains in email addresses.

    The MX-to-CNAME and CNAME-to-CNAME issues are unrelated. CNAME-to-CNAME
    works in the sense that clients which can cope with a single CNAME
    indirection correctly implement CNAME chasing, provided that chain is
    not too long to cause the DNS response not to fit into a 512 byte
    packet. (This has been emprically demonstrated by Akamai and others.)
    Some MTAs bounce mail targeted at MX-to-CNAME domains (IIRC, smail
    contains a configuration option to do this), so you should generally
    avoid this to avoid email reachability issues. And NS-to-CNAME doesn't
    work at all, BTW.


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  17. Re: seeking: Ian Jackson

    also sprach Florian Weimer [2007.10.10.1145 +0100]:
    > RFC 1123 contains this requirement:
    >
    > 5.2.2 Canonicalization: RFC-821 Section 3.1
    >
    > The domain names that a Sender-SMTP sends in MAIL and RCPT
    > commands MUST have been "canonicalized," i.e., they must be
    > fully-qualified principal names or domain literals, not
    > nicknames or domain abbreviations. A canonicalized name either
    > identifies a host directly or is an MX name; it cannot be a
    > CNAME.
    >
    > This means that it's fine to use domains pointing to CNAMEs in Internet
    > mail.


    I think it says exactly the opposite, don't you?

    --
    .''`. martin f. krafft
    : :' : proud Debian developer, author, administrator, and user
    `. `'` http://people.debian.org/~madduck - http://debiansystem.info
    `- Debian - when you have better things to do than fixing systems

    if loving linux is wrong, i don't want to be right.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFHDLG3IgvIgzMMSnURAsHlAJ4w6O/cEkUflEsS8375VsjVNfaktACg61qM
    aRbmy13PZxBYXwoN9BU94nY=
    =VrAM
    -----END PGP SIGNATURE-----


  18. Re: seeking: Ian Jackson

    * martin f. krafft:

    > also sprach Florian Weimer [2007.10.10.1145 +0100]:
    >> RFC 1123 contains this requirement:
    >>
    >> 5.2.2 Canonicalization: RFC-821 Section 3.1
    >>
    >> The domain names that a Sender-SMTP sends in MAIL and RCPT
    >> commands MUST have been "canonicalized," i.e., they must be
    >> fully-qualified principal names or domain literals, not
    >> nicknames or domain abbreviations. A canonicalized name either
    >> identifies a host directly or is an MX name; it cannot be a
    >> CNAME.
    >>
    >> This means that it's fine to use domains pointing to CNAMEs in Internet
    >> mail.

    >
    > I think it says exactly the opposite, don't you?


    There's a difference between Internet mail and SMTP. Internet mail
    addresses (which are passed to /usr/sbin/sendmail, for instance) must be
    canonicalized before they are used in SMTP. At least that's the theory;
    Exim doesn't do it.

    Is this still unclear? I don't really know how to explain this more
    clearly.


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  19. Re: seeking: Ian Jackson

    On Wed, 10 Oct 2007 22:42:35 +0200, Florian Weimer wrote:
    [...]
    > Internet mail
    > addresses (which are passed to /usr/sbin/sendmail, for instance) must be
    > canonicalized before they are used in SMTP. At least that's the theory;
    > Exim doesn't do it.


    And apparently on purpose:
    Exim deliberately doesn't do this. We had no end of trouble in the days
    before I wrote Exim with other MTAs that made dreadful messes in this
    area, so I stayed well clear.
    Although, as usual, it can be forced to if need be.
    http://bugs.debian.org/75933

    --
    Micha│ Politowski
    Talking has been known to lead to communication if practiced carelessly.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFHDUA9fe5k6+27tW8RAkGBAJ9qYBy3js+Q3TDvLH9PwL YdKjmHMACffP3f
    FfropmLQOpwDOZA4paNWAcQ=
    =k9iS
    -----END PGP SIGNATURE-----


+ Reply to Thread