I see you don't believe in honouring the reply-to address (and in this
case, yes, I did receive both of your replies -- odd how you can make
your personal domain work better than the "corporate" ones.....)
[ On Wednesday, September 19, 2001 at 15:09:04 (-0700), Marc MERLIN wrote: ]
> Subject: Re: [Exim] Trying to compare HELO data with actual host info in a filter...
>
> > Yes. You are clearly violating paragraph one of RFC 1123 section 5.2.5.
> >
> > Regardless of what paragraph two says I'm holding you to the rule in
> > paragraph one.
>
> Let's see:
> "The sender-SMTP MUST ensure that the <domain> parameter in a HELO command is
> a valid principal host domain name for the client host. As a result, the
> receiver-SMTP will not have to perform MX resolution on this name in order
> to validate the HELO parameter."
>
> magic.hdqt.valinux.com is "a valid principal host domain name for the
> client host".
No, it clearly is NOT:
$ host -a magic.hdqt.valinux.com
magic.hdqt.valinux.com does not exist (Authoritative answer)
> It doesn't say anything about it having to be resolvable by you.
Get real Marc! You cannot expect the RFCs to define the difference
between private DNS and public DNS. The private DNS is obviously
irrelevant. The only concern in the RFCs, especially in this case, is
with public DNS and public visibility of the domain names being used.
> For that
> matter, it says that you are not supposed to perform a lookup on it.
Where, pray tell, does it say that?
Not even in the second self-contradictory paragraph. Indeed there's
even explicit mention of the potential for such verification (all I'm
disputing is the decade-old unreality of not doing anything active about
a failed verification -- and I'm far from being alone on this as every
major mailer available supports an option to do such verification).
> Both are configured quite fine, thanks for enquiring. I explained the setup
> here as a valid example of why the domain in EHLO doesn't have to be the IP
> you see a connection from (NAT), and you conveniently ignore it.
Your explanation has only shown one thing -- that you have a fundamental
mis-understanding of how the public Internet works.
You obviously are trying to justify a broken configuration -- perhaps
only because you don't know how to fix it..... How am I supposed to
know? You're obscuring your network in uncommon ways for unknown
and un-declared reasons.
I'll bet you a mug of beer that you're lying about how many mailers will
reject mail from sourceforge (and likely from valinux.com) due to the
failed HELO check. I know for certain that my site isn't the only one
that's implemented such checks. Why even some Exim users do the same!
> > BTW your DNS setup is still broken too. Simple queries with a tool like
> > 'host' point these out with glaring clarity. For example.
> >
> > $ host -A mail.sourceforge.net
> > !!! mail.sourceforge.net address 216.136.171.198 maps to usw-sf-lists.sourceforge.net
> >
> > $ host -A externalmx.VALINUX.COM
> > !!! externalmx.VALINUX.COM address 198.186.202.147 maps to panoramix.valinux.com
>
> Yeah, so? Are you going to show me an RFC that says that rDNS has to
> magically map back to all possible domains MXed to a box?
Hmm -- do I really have to? Can't you read them for yourself? This
particular rule is as old as the hills. Users of TCP Wrappers have
enforced it for nearly half a decade now!
> Or maybe is it forbidden to have multiple As pointing to the same IP now?
No, definitley not. Multiple PTRs with different target names are
explicitly permitted, just as are multiple A RRs with different target
IP addresses. All that matters is they be in full orthogonal
consistency.
> rDNS and fDNS match, that's all you should care about.
Obviously they don't match. You only have one PTR for each, and they
clearly don't match the names above:
$ host -i -a 216.136.171.198 NS.EXODUS.NET
198.171.136.216.in-addr.arpa PTR usw-sf-lists.sourceforge.net
$ host -i -a 198.186.202.147 ns1.valinux.com
147.202.186.198.in-addr.arpa PTR panoramix.valinux.com
Now the fact that the names they do point to have corresponding IP
addresses is indeed "good enough" for TCP Wrappers (and for me, though I
would rather see *everything* match).
> Either way, this is not appropriate for discussion here, you can send your
> complaints to the postmasters of the respective domains, and your Emails
> will continue to be ignored as long as you keep bouncing answers.
> Using the exim mailing list to get support because you can't receive mail is
> not an appropriate use of the list.
Hmmmm..... what about that Reply-To: again? Seems to me you're the
one who's trying to defend yourself in public here.... I've never tried
to give excuses for my actions -- I just document what they are and the
reasons I decided to take them. I make no excuses and no exceptions.
> I can't make the error message more clear:
> "Are you sure your domain in From: and/or Reply-To: resolves from the
> internet (host -t MX domain) and can be connected back to for delivery of
> replies"
Duh. Of course I am -- and your own nameservers and tests confirm, and
all would be fine if your broken configurations were corrected....
Of coruse now that I know you're actually making a SMTP connection to
try to verify the address I'm quite amazed. You are the first site I've
known to be doing this on any scale (Brad Knowles considered it for AOL
once upon a time, but so far as I know it was never implemented since
the folley of it was apparent even to Brad). I'm very surprised that
you're doing this for <postmaster> mail too though.... Quite brave of
you.....
> Thank for you demonstrating my original point, which was that doing
> verifications on the domain given in HELO was stupid.
and your SMTP call-back checks are any more brilliant? good go Marc!
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@???> <woods@???>
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>
