ietf-smtp
[Top] [All Lists]

MX Domain Name --> Was Re: Some Ideas I would like to Bounce off ya

2004-02-10 15:21:26


----- Original Message ----- 
From: "Keith Moore" <moore(_at_)cs(_dot_)utk(_dot_)edu>
To: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>
Cc: <moore(_at_)cs(_dot_)utk(_dot_)edu>; 
<Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu>; <ietf-smtp(_at_)imc(_dot_)org>
Sent: Tuesday, February 10, 2004 1:25 PM
Subject: Re: Some Ideas I would like to Bounce off ya



Valdis was exactly right.    And I don't know why he or anyone else should
waste
his time responding to every one of your proposals in detail.

Like I said, if he or you can "Baffle me with Brilliance," then GREAT!,
Neither of you have, nor provided reason yet to reject it but to suggest
"Hey stupid, I know better. Go away."     It is obviously you don't the get
into the details issue of what is being proposed for SMTP developers because
you aren't a developer. So things like this don't seem bother you,.

But if you care to see WHY this is a problem and why a MX solution may help,
here is why:

The details of a LOG is shown below:   Here is the summary:

Valdis attempts to sent mail to me with the ip, EHLO and MAIL FROM
information:

        connection ip:   128.173.54.129
        machine domain:  turing-police.cc.vt.edu
        return path: valdis(_dot_)kletnieks(_at_)vt(_dot_)edu

With these basic information,   a DMP and SPF lookup would of failed.   Two
TXT lookups would of been performed for DMP:

        129.64.173.128.in-addr._smtp-client.vt.edu
        129.64.173.128.in-addr._smtp-client.turing-police.cc.vt.edu

For SPF, a 4 more TXT lookups:

        _spf.vt.edu
        vt.edu
        _spf.turing-police.cc.vt.edu
        .turing-police.cc.vt.edu

In all 6 lookups would fail.    It is TURNED off because of the high
overhead expense of looking up other domains other than your own.

In order for valdis (and you too) to operate in the future world of LMAP, he
will will have to add atleast 1 TXT record for SPF support only and atleast
4-6 more TXT records for DMP support to reflect that IP address and that
machine domain name in his DNS setup.

However, if you havn't walked away yet,  the LOG below shows how a CBV was
performed to validate his return path where a MX lookup was performed and a
smtp-base validation was performed.

Now, all I was proposing that there MAY BE no difference in current MX
compatibility (hoping this is where you can prove it wrong) if he simply did
this:

Instead of having the host domain name

        smtp.vt.edu

have instead:

        smtp.RECEIVER-NO-SPAM.vt.edu     ip: 198.82.161.8
        smtp.SENDER.vt.edu        ip: 128.173.54.129

(please don't forcus on the actual tags)

because now we have a MX lookup that addresses all concepts such as

    o validating the sender machine as intended by the LMAP proposals,

For those who might to go further, they can double check to see if the a
host is available for return path notifications if necessary with 1 single
MX lookup.

More importantly, it should break anything,  except maybe with the above, an
attempt might be made to send mail to the SENDER machine.   So maybe if this
idea has any merit, could it be done with a single record domain name such
as:

        smtp.RCVD-SENDER_128.173.54.129.vt.edu     ip: 198.82.161.8

This would not CHANGE any thing other than changing the name of domain.

Do you know if any particular reason why a MX domain name concept can not
work here?


-- Detail send authentication log of Valdis sending mail to me --

20040210 11:48:13 -------------------------------------
20040210 11:48:13 version    : 1.54 / 1.52
20040210 11:48:13 calltype   : SMTP
20040210 11:48:13 callerip   :
20040210 11:48:13 lanip      : 208.247.131.9
20040210 11:48:13 state      : rcpt
20040210 11:48:13 cip        : 128.173.54.129
20040210 11:48:13 cdn        : turing-police.cc.vt.edu
20040210 11:48:13 from       : <valdis(_dot_)kletnieks(_at_)vt(_dot_)edu>
20040210 11:48:13 rcpt       : 
<winserver(_dot_)support(_at_)winserver(_dot_)com>
20040210 11:48:13 ruid       : 228761
20040210 11:48:13 srvdom     : winserver.com
20040210 11:48:13 srvip      : 208.247.131.9
20040210 11:48:13 srvsock    : 484
20040210 11:48:13 sapfilter  : pass
20040210 11:48:13 sapdmp     : skipped
20040210 11:48:13 sapspf     : skipped
20040210 11:48:13 saprbl     : testing 129.54.173.128.sbl.spamhaus.org
20040210 11:48:14 saprbl     : testing 129.54.173.128.list.dsbl.org
20040210 11:48:15 saprbl     : testing 129.54.173.128.bl.spamcop.net
20040210 11:48:16 saprbl     : pass
20040210 11:48:17 sapcbv     : total mx records: 1
20040210 11:48:17 try mx     : smtp.vt.edu ip: 198.82.161.8
20040210 11:48:17 # connecting to 198.82.161.8
20040210 11:48:17 S: 220 zidane.cc.vt.edu ESMTP Mirapoint 3.4.3-CR; Tue, 10
Feb 2004 11:46:44 -0500 (EST)
20040210 11:48:17 C: NOOP WCSAP v1.54 Wildcat! Sender Authentication
Protocol http://www.santronics.com
20040210 11:48:17 S: 250 OK
20040210 11:48:17 C: HELO mail.winserver.com
20040210 11:48:17 S: 250 zidane.cc.vt.edu Hello ntbbs.winserver.com
[208.247.131.9], resetting message state
20040210 11:48:17 C: MAIL FROM: <>
20040210 11:48:17 S: 250 <>... Sender ok
20040210 11:48:17 C: RCPT TO: <valdis(_dot_)kletnieks(_at_)vt(_dot_)edu>
20040210 11:48:17 S: 250 <valdis(_dot_)kletnieks(_at_)vt(_dot_)edu>... 
Recipient ok
20040210 11:48:17 C: RCPT TO: 
<wcsap-openrelay-test-123sxa23(_at_)alqwejad(_dot_)com>
20040210 11:48:17 S: 550 
<wcsap-openrelay-test-123sxa23(_at_)alqwejad(_dot_)com>...
Relaying denied
20040210 11:48:17 C: QUIT
20040210 11:48:17 sapcbv     : 250
20040210 11:48:17 result     : accept (-1)
20040210 11:48:17 wcsap finish (4547 msecs)

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com