>>>>> "NB" == Norbert Bollow <nb@thinkcoach.com> writes:
NB> There is no conflict between these two RFCs here.
I still believe there is, because they don't specify how to handle the
problem of "I took the long name like I SHOULD but I can't pass it on
because I MUST NOT".
If that isn't a conflict, I don't know what is.
NB> a) Disallow subscriptions from e-mail addresses with host names of more
NB> than 64 characters. (This will violate the SHOULD of RFC1123, so it's
NB> not a perfect solution, but at least it's not illegal.)
I will do this, configurably. (The address parser has some configuration
options, but they aren't currently made available anywhere in the code.
I'll probably make them global config options.) It's only a few lines of
code to make sure we have short enough strings on either side of the '@' in
the stripped address.
NB> b) Allow subscriptions of e-mail addresses with long host names, but
NB> never ever put host names of exceesive length into RCPT commands of
NB> SMTP, interactions, but convert these to the [#.#.#.#] form first. The
NB> DNS lookup for this would need to be done at the time of sending the
NB> message, and not at the time of the subscription request.
This is the wrong thing do do, because
1) there isn't any easy way to do do the DNS lookup. (The perl DNS modules
aren't yet ready for prime time.)
2) We are forced to do the DNS lookup at delivery time because of
round-robin DNS arrangements. This has speed penalties. (Sure, it's
probably going to happen somewhere down the line anywhere, but that
might happen on a different machine with a preloaded DNS cache.)
3) Doing this defeats any and all MX arrangements in place. The IP address
of the host might not even accept mail. (So we do a multilevel DNS
lookup to get the address of one of the MX hosts and hope that it isn't
down. And then we're as complicated as sendmail for no benefit and more
bugs.)
NB> I admit that option b) is ugly, but it shows that it is possible to
NB> honor the SHOULD of RFC1123 without violating the "must not" of RFC821.
Sure, if you want to be illegal with respect to some other things in the
process.
I do wish a real RFC lawyer would take a look at this. It's taken me
longer to try to figure out the RFCs than to code the fix.
- J<
Follow-Ups:
References:
|
|
