RE: [Asrg] seeking comments on new RMX article

["Tom Thomson" <[e-mail]>]

> Why would I write it up when the authors of RFC 821 and RFC 2821
> already did?  Or have I misunderstood section 4.1.1.1 of RFC 2821 and
> section 3.5 of RFC 821?

Yeah, OK, my bad - sometimes I manage to say the stupidest things.  The
point I meant top make was that it's now a domain name not a hostname, and a
domain name doesn't necessarily have a corresponding IP address because it
may not be a hostname.

> Please also consider the possibility that since I do not favor RMX,

That's something we have in common - I just object to arguments against that
appear not to be based on the technical and practical realities.

> I also do not favor this check.

Neither do I!

> If the requirement that the HELO
> value be the MTA's domain name were not more than 20 years old, I
> would be unlikely to spend much time documenting it.

If you go back 20 years it's <hostname> not <domain>.  Also, the requirement
isn't generally observed (which I think is a pity, so I probably disagree
with you on that).

> > >The reason to check reverse DNS name is to cover the case when the
> > >SMTP client is authorized to send mail for more than one domain name.
> >
> > Some MTAs will need (tens of) thousands of rDNS answers - quite a big
DNS
> > transaction to get all those back (unless of course you are proposing
that
> > no host can act as outgoing MTA for more than one domain - now that
would
> > cause quite an upheaval, probably do more economic damage than all the
> > spammers in the world).
>
> Yes, MTAs processing lots of mail make many reverse DNS lookups, but
> checking reverse DNS names would not require additional DNS lookups
> for most mail.  The reverse DNS name of the SMTP client for most mail
> is already checked by SMTP servers.  That is how SMTP servers add
> Received:  headers naming the SMTP client.

That only flies if the rDNS is present.  The times when it isn't present are
the times when the alternative would be to have very large numbers of
reverse addresses entries, so that there would be a very big overhead on
mail sent.

> > Even then, it just doesn't work: the MTA you see is the ISPs outbound
MTA
> > (many ISPs block port 25, of course, so their users have to relay
through
> > the ISP's outbound MTA), not the originator's mail client machine, and
the
> > originator's mail client machine will not have the same domain name as
that
> > MTA (unless of course part of your proposal is to allow lots of hosts
owned
> > by lots of different organisations all to have the same domain name
instead
> > of having domain names connected with the organisations, which is rather
a
> > big change to the internet as we currently understand it).
>
> What's that about "doesn't work" and "big changes"?  Common MTA software
> including sendmail can say "possibly forged" or similar comments when
> confronted with mismatches.  It is also trivial to tell sendmail to
> reject mail that fails such checks among sender address, reverse DNS
> name, and HELO value, because sendmail already makes the DNS lookups
> and then checks the values.

Well, try this for an example.  Five small companies have their own domains.
They all use the same ISP.  They all use the ISP's MTA for trannsmission.
So when your receiving MTA sees email it has an envelope MAIL-FROM
specifying perhaps [e-mail] and a helo <domain>  bigisp.fr and the
rdns of the ip address of the MTA is smpthost1.rouen.bigisp.fr.
Neither the rDNS value nor the helo domain matches sc1.fr so the mail fails.
Similarly, when the [e-mail] sends, sc2.fr doesn't match so the
mail fails. And so on.  That's if it even gets that far - does
smtphost1.rouen.bigisp.fr match isp1.fr, or do you refuse teh connection
because it's not the same string?  Or does the problem get fixed because the
ip address of that MTA has lots of rverse records - all of
smtphost1.rouen.bigisp.fr, sc1.fr, sc2.fr, sc3.fr, sc4.fr (and two thousand
more completely separate domains of two thousand more small companies in
southern Britany which just happen to use this ISP) as well as also
bigisp.fr?  If most of the MTAs on the net implement the checks as you
describe, then either such a machine does indeed have thousands of reverse
DNS records or biisp's business model is somewhat broken and he'd better
stop blocking port 25 (and as he hasn't done that, doesn't have 2537 reverse
DNS records for that IP address, and hasn't gone bust yet either, I think
you may be mistaken).  Now of course if all those small companies and their
ISP all renamed their domains so that they had the same domain name, and all
their individual machines each had the same hostname, this multiplicitly of
domain names for which the MTA is acting would go away - but it wouldn't be
any part of the internet as we know it today.

> Many messages ago in this mailing list Paul Vixie pointed out that MX
> records can do today exactly what rMX might do someday with a new, to
> be defined RR.  He pointed out that most outbound MTAs are also inbound
> MTAs and so are named by MX RRs (or there are no relevant MX RRs and
> their A RR serves the same purpose).  Outbound MTAs that are not
> inbound MTAs and so do not answer port 25 need only have new MX RRs
> defined with very large preference.

Paul Vixies proposal had MAIL FROM MX records, the priority in them was not
very large but 0, and he carefully pointed out the issue of inbound and
outbound MTAs being not the same (and provided an example of the two
distinct sets of ordinary MX records and MAIL FROM MX records which
illustrated this) rather than claiming that mostly they were the same
(unless I've been reading a proposal by a different bloke with the same
name, which is of course possible if you've managed to impose on people the
sort of change you seem to suggest would be acceptable for hosts and
domains).  I think you do him a disservice by misinterpreting his very
useful work.

Tom


_______________________________________________
Asrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg