Subject: Re: [Asrg] seeking comments on new RMX article

From: Scott Nelson <[email-masked]>
Date: Mon, 05 May 2003 08:40:30 -0700

At 05:04 PM 5/5/03 +0200, Hadmut Danisch wrote:
>On Sun, May 04, 2003 at 04:11:01PM -0700, Scott Nelson wrote:
>
>> Draft-danisch-dns-rr-smtp-01.txt mentions that receiving servers
>> are free to drop email that doesn't have an RMX record.
>
>The mail shouldn't be dropped, it should be rejected in order
>to give the sending MTA a chance to generate an error message.
>

I could swear that I read "may be dropped" in the proposal, 
but now I can't find it.  My bad, sorry.

Scott Nelson <[email-masked]>

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

---

From: "Eric D. Williams" <[email-masked]>
Date: Mon, 5 May 2003 11:53:57 -0400

Perhaps the issue here is not mail transport at all.  In face I think what is 
at issue is gaining access to an MTA and not the mail transport protocol at 
all.  Let's say mobile user 'A' wants to send eMail.  She has multiple methods 
for accessing the MTA but only one mail transport.  The mobile user MAY 
leverage some other 'session transport' protocol to gain access to her 
applications MTA transport protocol.

If this is a valid scenario then a mobile user MAY not have to utilize 
'arbitrary' hosts in the 'void' to enable mail transport.  I am not clear why 
but the use of arbitrary disturbs me in this context I would be more 
comfortable with "assigned" or "designated."  Although I do understand why the 
term 'arbitrary' is apropos.

-e

On Sunday, May 04, 2003 9:56 PM, Dave Crocker [SMTP:[email-masked]] wrote:
> Mike,
>
>
> AD>> Are there NO other methods which a mobile user may use to send mail?
>
> MR> What about VPN?  What about stunnel?
>
> those are not mail protocols.
>
> MR>   What about smtp-auth?
>
> smtp-auth is an option to smtp.  so, it is smtp.
>
> MR>   What about
> MR> Courier's "outbox" for IMAP over SSL?
>
> I don't know what you are referring to, but it is not an Internet
> standard for posting mail.
>
>
> MR>   Heck, what about ssh tunnels?
>
> not a mail protocol.
>
>
> MR> Perhaps I'm not understanding your objection?
>
> possibly.
>
>
>
> d/
> --
>  Dave Crocker <mailto:[email-masked]>
>  Brandenburg InternetWorking <http://www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
>

---

From: "Eric D. Williams" <[email-masked]>
Date: Mon, 5 May 2003 11:46:40 -0400

On Sunday, May 04, 2003 9:45 PM, Mike Rubel [SMTP:[email-masked]] wrote:
8<...>8
> AD> Used properly, RMX doesn't prevent anything.  It simply allows the
> AD> recipient MTA to make faster, better decisions about how to deal with
> AD> the email.
>
> SN> "used properly" aye - there's the rub.
> SN> Draft-danisch-dns-rr-smtp-01.txt mentions that receiving servers
> SN> are free to drop email that doesn't have an RMX record.
> SN> That may be true, but IMO it isn't best practice.

Yes it may not be Best Practice, however that does not 'matter' for the 
specification it would matter on implementation (which is in this case is left 
to the discretion of the administrator and/or developer) or configuration.

> Receivers are free to do anything they like with the email; I had pictured
> RMX providing information to (for example) spamassassin.

That is a salient point and addresses one of the concerns with proposal 
requirement recently introduced:

On Sunday, May 04, 2003 12:26 PM, Alan DeKok [SMTP:[email-masked]] wrote:
>   Based on recent discussions, I would suggest an update to the requirements:
>
> > 1.	must minimize unwanted messages to some acceptable level
> > 2.	must not affect delivery(latency, integrity, cost, reliability) of
> >  	wanted messages to a point that would effect the normal use of email
>
>   2a) must not require that any message be accepted or rejected
>
>   Much of the discussion around anti-spam systems indicates that most
> people think that anti-spam systems are "either-or" type of systems.
> i.e. As a result of applying the system to the message, it is either
> accepted or rejected.  I would like to discourage such thinking.
>
>   Anti-spam systems should be designed to give the local administrator
> more information with which to make accept/reject decisions.  The
> systems themselves hould not require that the adminstrator do anything
> with the message, as the action taken after deciding a message is spam
> is entirely up to local site policy.

I agree with Alan's assessment and it appears to be addressed by the comments 
suggested.

> SN> The questions I have are;
> SN> What percentage of the people who use it will use it improperly?
> SN> And what happens when it's used improperly?
>
> If it's used improperly, then mail gets dropped--the same thing that
> happens when the recipient's mail server or DNS is configured improperly,
> or if its spam filter is too aggressive.  Users complain, and the system
> gets fixed.

Exactly.

> RMX is about the least-complicated (and therefore least error-prone)
> solution to this problem that I've seen, though.  Do you know of other
> solutions are less likely to be used improperly?

I tend to agree with that (as an incremental solution) e.g. forgery.

-e

---

From: "Eric D. Williams" <[email-masked]>
Date: Mon, 5 May 2003 12:41:02 -0400

On Monday, May 05, 2003 11:06 AM, Dave Crocker [SMTP:[email-masked]] wrote:
> Alan,

> >> so, what is the real utility of the rmx record?
> AD>   Umm... you have more information with which to make better
> AD> decisions?  That doesn't seem like a bad thing.

> Spam is about filtering bad guys.  RMX is about labeling good guys.

I think the premise is that RMX is about finding a method to give 
accountability.

> Hence, with RMX, you still know nothing about bad guys.
>
> How does it help to control spam if you continue to know nothing about
> the bad guys?

Part of the 'spam' problem lies in accountability.  I think the RMX proposal is 
incremental toward that end and not a 'spam' control proposal.  Some modicum of 
'spam' control is I suppose a side-effect or benefit of RMX.
>
> >> that is, what can you safely do, versus not do?
>
> AD>   For RMX systems, you can safely be more liberal in filtering
> AD> messages, because you have some level of confidence that any spam
> AD> coming from RMX systems will be traceable and accountable.  That
> AD> doesn't seem like a bad thing to me.
>
> What does this mean, exactly?  A different set of filters for RMX-based
> mail?  The idea of maintaining two rulesets is a bit daunting.  Seems
> unlikely to scale.

I do not think scaling of RMX is overly burdensome but you raise an interesting 
point via this argument.  Would RMX be better served by an 'accountability' 
extension that handles/gives feedback, concerning determinations based on RMX?

> >> AD>   Are there NO other methods which a mobile user may use to send mail?
> >>
> >> no.
>
> AD>   I disagree most strongly.
>
> >> AD> SMTP is only one of many protocols used to send/receive email.
> >>
> >> interesting.  i believe there are no others.  ("submit" is simply smtp on
> >> another port.)  which ones are you referring to?
>
> AD>   Some people have posted other alternatives.
>
> no they have not.
>
> On the modern Internet, all of the mail posting semantics are achieved
> with SMTP.

I agree, SMTP has evolved into a ubiquitous transport between messaging systems 
that use alternative (non-Internet) based local transports.  In fact it could 
be argued that SMTP has usurped many of those 'proprietary' transports to a 
large degree.

> The "alternatives" presented were for alternative lower layers, or for
> extremely limited email protocols that will never gain large-scale use.
> (They have been around long enough to demonstrate this limitation
> clearly.)
>
>
> AD>  An additional one is
> AD> mail via a web interface.
>
> oh boy. now you are going to propose an array of non-standard user
> interfaces as an email posting protocol?

As I mentioned in a previous message, I think that is not the point which is 
being proffered.  I think there is congruence on the messaging transport idea 
but where the element of mobility has been introduced there are different ways 
to attack the mobility problem.

> methinks we have left the world of technical discussion of spam control.
>
> the work here needs to be about protocols.

I agree but where in the stack will it/they sit?

>
> AD>   The feeling I get here is the same from everyone who's requiring
> AD> that mobile users be allowed to send SMTP traffic to any port 25 on
> AD> the planet, and to pretend to come from any domain.  They're adamant
> AD> that that's the ONLY way they can send mail from remote sites, and
> AD> that there are NO other workable alternatives.
> ...
> AD>   I'm at a loss to respond to such a position.  It's so trivially,
> AD> obviously wrong, that I'm left wondering what I'm missing.
>
> You are over-interpreting my statements.  They were written carefully.
> Please read them the same way.
>
> By way of seeking something constructive out of this, would someone who
> believes there are viable alternatives to SMTP -- and that they will
>
>      a) solve or at least reduce the spam problem,
>
>      b) match SMTP's functionality, and
>
>      c) stand some chance of being adopted by the Internet's 100 million
>      users

"c)" is/was a sticky point but I think you may agree that in the universe of 
potential specifications at least X.400 at one point was a proposed candidate, 
however interoperability being a key concern (among the implementors) and the 
'testing' labs were a fait accompli on adoption and led to the ultimate demise. 
 At least as a message posting and transport scheme.

> please put forward a technical specification of this "viable"
> alternative, so that it moves from a general idea into something
> concrete.
>

-e

---

From: "Eric D. Williams" <[email-masked]>
Date: Mon, 5 May 2003 12:50:26 -0400

On Monday, May 05, 2003 12:01 PM, Alan DeKok [SMTP:[email-masked]] wrote:
> Dave Crocker <[email-masked]> wrote:
>   I don't quite agree.
>   Right now, we have a pool of SMTP originators.  The pool contains
> both good guys, and bad guys.  It's difficult and expensive for any
> recipient to distinguish between them.
>
>   With tools like RMX, a recipient can easily seperate the pool into
> "accountable" originators, and "unknown" originators.  This means that
> the bad guys are more likely to be marked as bad guys, and the good
> guys less likely to be so marked.  While this doesn't give you direct
> information about the bad guys, it does give you indirect information:
> They're not the good guys.
>
>   In summary, RMX allows us to increase our confidence in the marking
> probability for bad guys.

I don't quite agree.  I would say:

You increase your pool of known origination points, RMX does not control 
spammers (at all) end system policy would perform that trick, RMX would enable 
the end system manager to establish additional policy controls based on 
'relevant' criteria, nothing more.  It would be just as useful for a spammer to 
use RMX (though if they are engaging in forgery less likely) in order to 
counteract lax policy controls based upon RMX.

-e

---

From: "Sauer, Damon" <[email-masked]>
Date: Mon, 5 May 2003 12:16:31 -0500

>> Please recite your experiences with Malaysian ISPs, US ISPs, Bolivian
>> ISPs and Tunisian ISPs.  They, too, must accomplish adoption before the
>> proposed mechanism is useful.

>I agree, that the 'Old Europe' might be faster than the rest of the
>world. Second and Third world countries must be forced to upgrade,
>because that's where the Spam comes from that is unreachable by law.

I would also like to bring up the point- Look at all the people that would
implement RMX's it right away...
AOL, Hotmail, Yahoo, and any major ISP that is having a spam problem. (Isn't
that everyone?)
 No longer will a spammer be able to say they are from a domain that is
using an RMX (being received by a system that is checking for them). Sure,
they can say they are from YaMoo.com- but no longer will they be able to say
they are from Yahoo.com.
 As RMX's go into place, that is one less domain that a spammer can spoof. I
don't see this as a solution that only works once it is fully implemented...
the benefits are immediately realized once the very first RMX record is
published for Yahoo or Hotmail.
 I will implement them immediately to keep spammers from using the corporate
domain name for my company as a rejection notice dumping ground and stop the
angry letters from people who don't know how to read headers.
 At some point I am sure that we will have to "force" this issue, in that we
will not wait for ISP X any longer. (Z)% of the internet is using it and if
they are the last hold out- Sorry- Fix it, because it is now broken.

 I am sorry I have not been participating lately. The discussion just got
too noisy and I have real work to do ;-)

Regards,
Damon Sauer
If I had a nickel for every spam message I have blocked.... I would have ALL
the nickels!

*****
"The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material.  Any review, retransmission, dissemination or other use
of, or taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.  If you received
this in error, please contact the sender and delete the material from all
computers."
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Eric D. Williams" <[email-masked]>
Date: Mon, 5 May 2003 16:39:48 -0400

On Monday, May 05, 2003 1:20 PM, Vernon Schryver 
[SMTP:[email-masked]] wrote:

> Yes, but that's got nothing to do with getting spammers into the open
> and nothing to do with RMX or other mail virtue certificates until
> the mail from at least 80% of the Internet or 400,000,000 people uses
> them.  How long do you think it might be until RMX or any technical
> anti-spam system could reach 80% use?

I don't consider that a valid argument against a proposal.  First, it is at 
best a baseless conclusion, no one knows what percentage of RMX or any other 
proposal would have to be in place to be 'effective' and we don't have a 
consensus algorithm to determine effectiveness anyway. Second (this is my 
bugaboo on your paragraph) what percentage of sites use filtering? Has that 
affected spam?  I don't think this element of your argument makes a difference 
as to whether RMX is a viable incremental proposal for addressing the issue of 
forgery.

> > ...
> > > However, unless you are spammer fighter interested in attacking
> > > spamemrs, you don't care who or where the spammers are if you can
> > > simply arrange to not receive their junk.
> >
> >   I agree.  But I don't think such arrangements are trivial, or easily
> > made.
> >
> >   Making more people accountable for their behaviour is just one more
> > tool in the fight against spam.  I've never claimed that any tool is
> > perfect, or that it will do everything.
>
> RMX records do nothing I can see to making people accountable for
> their behaviour ever, and certainly not until the mail of 100's of
> millions of people use them.

I do not agree with your second clause.  A single large provider or a number of 
large providers pursuing actions against 'spammers' identified via RMX (for 
example) could have a large effect.  This as you state would not affect 
behavior, but, I think you may agree accountability is a viable goal 
(incremental though it may be) towards better 'spam' controls.

> What is your agenda for flogging something that cannot have any effect
> for decades?  Or are you claiming RMX records might be used on more
> than 80% of mail within 10 years?   If so, please justify that claim.

I do not think that is the goal of RMX, in fact I don't think RMX is related to 
mail messages but to the MTA that originate and relay messages.  So a more 
exact statement would be 80% of MTAs, I don't know what the threshold for 
effectiveness is, but any effect above 0% is something to consider enhancing 
(whatever the proposal) or determining whether it can scale to large deployment 
at all.  RMX I think CAN scale.  That is not an endorsement of the particular 
approach per se, but it seems to be a salient metric.

> What does any of that have to do with stopping spam?  What does knowing
> that one of UUNet's resellers has validate a mail sender as
> [email-masked] tell you?

If a reseller has validated an MTA in such a system [RMX] then you can attempt 
to make the reseller accountable for 'spam' origination.  It does not stop 
'spam'.  I think RMX would only validate the domain/IP address set not an eMail 
address per se.

> Do you check the whois records for the domains advertised in spam?
> What do you learn from records like
> http://opensrs.org/cgi-bin/whois.cgi?action=lookup&domain=gamingclub.com
> What would RMX tell you that whois records and IP addresses don't?

I think the whois is another spam fighting/accountability tool.  What RMX 
proposals seem to do is attempt to enhance discovery of forgery for an MTA and 
push it toward the edge of the policy boundary, although lax policy boundaries 
(an Internet mainstay) can easily short-circuit this effect.

-e

---

From: "Eric D. Williams" <[email-masked]>
Date: Mon, 5 May 2003 16:50:28 -0400

On Monday, May 05, 2003 1:30 PM, Vernon Schryver 
[SMTP:[email-masked]] wrote:
> > From: "Eric D. Williams" <[email-masked]>
>
> > Is RMX a proposed change to existing Internet services OR, 1) a proposed
> > extension to/of existing services? 2) an additional use of existing
> > services?
> > 3) a new protocol?
> >
> > My read is that it is #2 above.  The RMX proposal do not seem to constitute
> > a
> > change to existing services but rather a leveraging of those services to
> > achieve a specific goal.  It also seems to be application specific as
> > opposed
> > to a networking protocol.
>
> Yes, but what is your point?
>   - Have you noticed much use of DNSSEC?
>   - How about some of the major improvements in the not so recent
>      update to the HTTP protocol?
>   - SMTP-TLS has been available for years, but this mailing list is not
>      using it.  Do the SMTP servers or clients near you use it?
>
> Then there are RIPv2, IPv6, TCP-SACK, and TCP-ENS.  Even TCP
> slow-start took most of 10 years, and that was in the old days when
> the net was tiny and well controlled.

No internet protocol started with ubiquity AFAIK, some have not been adopted 
after being 'standardized' some evolved into de-facto standards before IETF/ISO 
(insert acronym) work was completed.  I do not think that these are valid 
measures of the viability of a proposal.  Also successful adoption IMHO is 
based on whether something 'gives the people what they want' and not 
necessarily 'what they need' or 'what they asked for'.

The paragraph you cite was inserted based upon Dave's post concerning changes 
to Internet services.  My point is I don't see the RMX proposal as a change to 
Internet services.  DNSSEC and SMTP-TLS are along the same lines.  Recall my 
opinion is that it may be 'what people need' or 'what they asked for' but is it 
'what they want'?  I think implementation difficulty also plays into the mix 
(on that I think we all agree).

> As the saying goes, "In theory there is no difference between theory
> and practice, but in practice there is."
>
> Would those who assure us that deploying RMX or any anti-spam scheme
> could be done in fewer than 10 years tell us about their credentials
> for making their authoritative sounding statements?  What protocol
> have they been involved in that was deployed as fast as their spam
> system would be?

I don't think any of us could boldly make such a claim as an individual, but 
surely that is not a criteria for evaluation of a proposal.  Achieving 
convergence and interoperation of a specification can be onerous (LDAP) or 
trivial (RFC822).

-e

---

From: "Sauer, Damon" <[email-masked]>
Date: Tue, 6 May 2003 08:53:34 -0500

<rant>

Alas,

 I am throwing my hands up again in disbelief. Did you folks even READ
Hadmut's proposal?!
Slow down DNS?!
Microsoft won't apply due to anti-trust issues?!
Are you on crack?!
You *know* what AOL will filter for and how they apply it? (I guess he
hasn't heard of weighted filters yet)
How many spoofed emails do you get? I get on the order of MILLIONS a day...
are you suggesting that the *better* solution is to stop all email until I
manually check each and every one?! ARE YOU NUTZ?!

 I will not comment further on Vernon and David's emails until they read and
apply Hadmut's proposal to their thought process before slamming it as
unworkable.

 This used to be a good thread. Now.... static.

 Here is an idea:
 Instead of adding personal conjecture or flame- try rejecting the proposal
via its technical merits by asking questions.

 e.g. Q: What about Dial-up users, do each of them have to add their own RMX
if they are running SMTP?

 See.. that was easier- Because the answer is straight forward and
non-confrontational

 A: If an ISP allows their users to use port 25 and have not closed it yet,
the RR for that ISP would be the range of IP's not specific ones x.x.x.x
/xxx

Q: What about people that run their own DNS servers?
A: If the ISP allows this, then one way or another, the RMX is going to be
added according to the infrastructure and will be allowed by the ISP if they
are also allowing you to run your own DNS. *REMINDER* RANGE OF IP'S CAN BE
ADDED TOO!

</rant>

Regards,
Damon Sauer

-----Original Message-----
From: Vernon Schryver [mailto:[email-masked]]
Sent: Monday, May 05, 2003 4:02 PM
To: [email-masked]
Subject: Re: [Asrg] seeking comments on new RMX article

> From: "Alan DeKok" <[email-masked]>

>   AOL, Yahoo, Hotmail.
>   Done.

Do AOL, Yahoo, and Hotmail have a total of more than 100,000,000 mail
users?  I don't think so, but if I'm wrong about that, I know that
that the RMX bits of AOL, Yahoo, and Hotmail would all say "any IP
address on the net can send mail with envelope Mail_From values of
our domain."  They all have many mail users that must send mail from
other ISPs and who are their mail users only because they can use AOL,
Yahoo, and Hotmail return addresses.

>   See, if those 3 companies decide that originators using RMX get
> "priority" service, I'll bet that a lot of sites will fall all over
> themselves adding RMX records to their DNS.

If the service is merely "priority" instead of "rejection," certainly
not.  In technical practice they cannot give better service to incoming
mail with RMX tags than without.  In fact, the cost of checking the
RMX RRs will slow down mail that has RMX records.

Those 3 companies won't decide to reject mail without RMX records
because their RMX bits will authorized all IP addresses everywhere.
Microsoft certainly won't because of anti-trust issues.   AOL won't
for the same reasons that caused AOL to abandone its old closed BBS
system.  AOL has jumped on some radical filtering, but only when it
had single digit false positive rates.  Today rejecting mail without
RMX bits would have a better than 99.99% false positive rate, and there
is no prospect that will change.

> ...
>   For one, I disagree with your idea that it will take decades.  I
> note that you have offered no proof for such a position.
>
>   In contrast, how quickly did domains add web servers in 1993-1994?
> I'll bet that if someone checked, probably 30% of active domains had
> web sites within 3 years.  That's a good timescale for something like
> RMX.

You'd lose that bet, unless you circularly define "active domains" as
those with HTTP servers.

> >  Or are you claiming RMX records might be used on more than 80% of
> > mail within 10 years?  If so, please justify that claim.
>
>   Nope.  Putting words into your opponents mouth is a well-known style
> of ad hominem attack, and one which astudiously avoids discussing any
> issues of substance.

In your message you twice claimed that RMX records will be very popular
in less than 10 years, including in your immediately preceding words.
Asking if that's your position is hardly inappropriate.

>   I'll go out on a limb: It allows me to track down that spammer, and
> potentially get them removed from the domain.  If the domain refuses
> to remove the spammer, then I have records which will justify my later
> filtering of ALL traffic from that domain.

Why do you need contact anyone before filtering all traffic from a
domain that has a pattern of supporting spammers?  What spam supporting
domains are you unable to identify today without RMX?

> ...
>   I'd be happy if RMX was used to add domains to blacklists.  Right
> now, domains have "plausible deniability" about spam from their
> domain.  Hotmail can say "Yes, they claim to be from hotmail, but they
> didn't use our MX, so it's not our problem."  RMX allows the recipient
> to refute that denial.

Why do you care about the plausible deniabilty of outfits that support
spammers?  If they are popular with spammers, why don't you just quitely
blacklist them?  Why do you need to count coup on them first?

>   I don't have the time, sorry.

My point is that the information you say you want and a lot more is
already available.

>   RMX, by design, explicitely exposes the originating domains intent
> to send email from an IP.  This intent is currently *implicit*.
>
> > By the way, that whois record told me to blacklist that domain.
>
>   That's your perogative.  It's a local policy issue, and it has
> nothing to do with general anti-spam policies.

My point was that the information you say you want from RMX
and a lot more is already available.  If you "don't have the time"
to deal with whois, then you won't have the time to deal with RMX.

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

*****

---

From: "Eric D. Williams" <[email-masked]>
Date: Tue, 6 May 2003 11:18:07 -0400

On Monday, May 05, 2003 3:40 PM, Vernon Schryver 
[SMTP:[email-masked]] wrote:
8<...>8
> ] From: "Eric D. Williams" <[email-masked]>
>
> ] ...
> ] I think the premise is that RMX is about finding a method to give
> ] accountability.
>
> ] ...
> ] Part of the 'spam' problem lies in accountability.  ...
>
> How so?  Why do you care who Alan Ralsky is, since you surely won't
> be sending him bomb threats or signing him up for junk postal mail.

It is my prerogative to act as I stipulate in policy, or not, relative to 
information I can gather.  The point is that appropriate policy can be defined 
at a policy boundary associated with an RMX result (whatever that is) and 
applied to my liking.

>
> Who cares who "Bill Zhang" of "Sunshine" in China really is, besides
> his ISPs and people who fight spammers instead of spam?

There is a flaw in this statement.  It pre-supposes what policy I will apply to 
an RMX result.  It remains a sysadmins responsibility (typically) to establish 
controls at the policy boundary.  That of course could be anything in the 
universe of options available to the sysadmin including rejecting, accepting, 
redirecting, forwarding, etc.

>                                                           As long as his
> ISPs connect his computers and those of his customers, what anti-spam
> accountability does RMX or any mail sender tagging scheme give?

I am not sure why you think of RMX as a tagging scheme, do you consider DNS a 
tagging scheme or a naming scheme?  Do you consider tagging and naming as 
merely a semantic distinction?  In any event my read is that RMX does not make 
a 'sender' accountable it allows the recipient system/administrator to make 
policy judgements based on objective information and if used by a spammer 
exposes the 'so-called' true authorized origination point for a domain (that's 
accountability).

>                                                                   If RMX
> or some other tagging scheme were universal, and if you could keep "Bill
> Zhang" from signing up for as many RMX tags as he has domains, one might
> argue that it could have some effect.  (He seems to make create several
> new domains/day.  Why don't the ICANN rules against his obviously bogus
> WHOS data make him "accountable" or stop him?)  It's trivial to recognize
> mail from "Bill Zhang" by checking the whois data on the domain names
> in his messages.  What is the difference between using port 53 or port
> 43 for "accountability" for his large volumes of spam?

To answer your question which I think is 'what's the difference with using DNS 
vs. WHOIS?' I don't believe there is a difference for domains that are listed 
in "From:" and "Received by:" headers that is accurate however, I think that 
RMX endeavors to address the problem of inaccurate information in that data 
set.  If I can know, for the purpose of establishing policy, that an IP address 
and domain do not match header information (in the context of the SMTP 
transaction) I consider that valuable information, even if it is only for 
post-hoc filter implementation.  As far as ICANN rules, the RMX proposal does 
not address that.

> What accountability is lacking but would be provided by RMX for the
> unsolicited bulk email from Verisign, American Express, Roving Software,
> Topica, and the rest of the Fortune 50,000 that would be our topic if
> the "Bill Zhangs" were not so productive?  The Fortune 50,000 send
> with unforged headers that point directly at themselves.

I don't think RMX is in effect either a legitimizer or eliminator of spam.  I 
do think that RMX provides a scalable, 'adoption-worthy', un-encumbered,

> The immediate purpose of RMX bits is to let SMTP servers compare IP
> addresses to sender domain names and so stop what some people call
> forgery.  However, the RMX bits for commonly "forged" domains including
> Yahoo, AOL, and Microsoft would say "all IP addresses can send from
> our domain", because they have significant numbers of users who use
> other sending ISPs.

I don't agree.  I think there are other means to establish domain/IP 
associations.  Specifically, modifications or extensions to DHCP or other 
dynamic configuration protocols may be valuable work to look into for this 
group.  In any event the introduction of any proposal, including RMX, does not 
eliminate the viability of other mechanisms e.g. SMTP-AUTH, SMTP-TLS, etc.

> Does SMTP-TLS enforce a valuable anti-spam accountablity?  SMTP-TLS
> has been available for years for free in the popular SMTP implementations,
> so why it used by less than 1%, not to mention more than 80% of the
> net?  Every organization with web pages that can be fetched by HTTPS
> has certificates that could be used with SMTP-TLS.  Most of those
> certificates are signed by major commercial PKI vendors.  Why isn't
> that "accountability" useful?  If it is useful against spam, why isn't
> it being used?  Why is the RMX accountability useful but the SMTP-TLS
> accountability useless?

I don't think measurement of adoption is a viable metric at this point unless 
it is associated with a failed concept or some that don't meet our minimum 
requirements.  Perhaps SMTP-TLS was not 'what the people wanted'.  Any proposal 
that can demonstrably show 'what the people want' does not necessarily have to 
be 'what the people need' or 'what the people asked for'.  Accountability is 
not tied to any specific proposal.  Accountability should, IMHO, be reviewed in 
any proposal as a requirement or goal.

> The underlying problem is that people who advocate RMX, TOES,
> authentication, or content tagging hope that some magic technology
> will finger spammers.  They don't want to be bothered with the standard
> work of collaring bad guys.  They don't care that counting coup on
> spammers by saying "I know who you are" never stops any spam.

I don't agree.  I think the problem is that we have not truly reviewed any 
approach that is the 'silver bullet' and probably won't ever see one.  As I 
said accountability is an important concept for formulating and establishing 
appropriate policy boundaries, knowing who someone is vs. who they purport to 
be is a valuable bit of information no matter where it comes from. 
 Establishing an appropriate policy boundary and effective (by some measure) 
enforcement controls is I think a consensus goal.  It is the method and means 
of doing that where we are focusing in this group.

>                                                                Those
> who are serious about fighing spammers instead of fighting spam don't
> need RMX or any of the other superficial quick fixes.  That's demonstrated
> in web pages such as http://www.spamhaus.org/rokso/

I understand your point, however I think with work RMX can be evolved into a 
more effective accountability mechanism, I am will to participate in that 
endeavor.  I don't understand what your premise is for the statement "Those who 
are serious".  I am serious about researching this issue to help formulate a 
set of solutions and approaches that CAN work.  I can not predict adoption or 
non-adoption and I do not attempt to evaluate the motives, resolve or agendas 
of the other participants in this group.  I would like to evaluate proposal 
using objective technical measures.

-e

---

From: "Eric D. Williams" <[email-masked]>
Date: Tue, 6 May 2003 11:49:31 -0400

On Tuesday, May 06, 2003 1:51 AM, Vernon Schryver 
[SMTP:[email-masked]] wrote:
>
> ] ...
> ] Is your argument is that IDENT is useless against spam, therefore RMX is
> ] useless against spam?  They're completely different animals...
>
> I think IDENT is in sendmail because it was supposed to be effective
> against spam.  It was not, and I think one major reason is that it
> never reached the critical threshold.

Side note: That is not the origin of IDENT protocol.  IDENT had nothing to do 
with 'spam'.  It is a completely different beast with a completely different 
and more esoteric origin.

> Besides, IDENT for mail seems very similar to RMX.  How would
> checking IDENT values for incoming mail differ from checking RMX bits,
> other than in trivial matters like using port 53 instead of 113?

Huh?  IDENT is not used for that type of purpose and should not be used to 
authorize or authenticate any activity on Internet.

-e

---

From: "Eric D. Williams" <[email-masked]>
Date: Tue, 6 May 2003 11:30:16 -0400

On Monday, May 05, 2003 9:02 PM, Daniel Feenberg [SMTP:[email-masked]] 
wrote:
>
>
> On Mon, 5 May 2003, Vernon Schryver wrote:
>
> >
> I think what is left unstated in this dispute is that the RMX proponents
> would like to discriminate among senders at a finer level than the IP
> address of the connecting host. They want to accept legitimate mail from
> spam-friendly connection IPs, and reject other mail. This would reduce the
> need for ISPs to "censor" their customer's incoming/outgoing mail, and the
> need for customers to find an ISP with a mail policy they can live with.

I don't follow that premise.  How does RMX lead to a '[desire] to accept mail 
from spam-friendly connection IPs, and reject other mail'?  How would the 
introduction of RMX affect my (recipient MTA) policy formulation in your 
example?

-e

---

From: "Eric D. Williams" <[email-masked]>
Date: Tue, 6 May 2003 13:47:06 -0400

On Tuesday, May 06, 2003 12:45 PM, Vernon Schryver 
[SMTP:[email-masked]] wrote:
> ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
>
> ] > I think IDENT is in sendmail because it was supposed to be effective
> ] > against spam.  It was not, and I think one major reason is that it
> ] > never reached the critical threshold.
> ]
> ] Side note: That is not the origin of IDENT protocol.  IDENT had nothing to 
do
> ] with 'spam'.  It is a completely different beast with a completely 
different
> ] and more esoteric origin.
>
> That was originally true, except for the "esoteric" bit.  However, if
> the origins of IDENT were a relevant objection, then it would outlaw
> RMX because DNS was not invented to deal with spam.

If it is originally true than it is true, is it not? Sure through away the 
esoteric bit, fundamentally IDENT was not created to function as a subordinate 
device for messaging systems.  I only added that to correctly in my opinion 
characterize the following:

   The Identification Protocol (a.k.a., "ident", a.k.a., "the Ident
   Protocol") provides a means to determine the identity of a user of a
   particular TCP connection.  Given a TCP port number pair, it returns
   a character string which identifies the owner of that connection on
   the server's system.

As you state IDENT nor DNS were developed to deal with 'spam'.  And that is the 
point I am arguing for, that existing technologies may be used to develop 
viable anti-spam proposals.

>
> ] > Besides, IDENT for mail seems very similar to RMX.  How would
> ] > checking IDENT values for incoming mail differ from checking RMX bits,
> ] > other than in trivial matters like using port 53 instead of 113?
> ]
> ] Huh?  IDENT is not used for that type of purpose and should not be used to
> ] authorize or authenticate any activity on Internet.
>
> Please justify that claim.  I think it is entirely wrong.  IDENT was
> invented precisely to add accountability for bad actors; never mind
> that I and many others argued from the start that it was a waste of
> effort and bandwidth.  That spam was not one of the original bad acts
> is also irrelevant.

The claim is one of application of best security practices and as stated by the 
security considerations in the IDENT RFC 1413, as I believe you know. 
 Additionally, IDENT logging MAY be used as 'auditing' information for TCP 
connections, it should not be relied upon to make decisions such as those 
associated with policy boundaries (authorization, access control).  That is my 
read on the RFC 1413.

> Consider http://www.sendmail.org/~ca/email/doc/op-sh-2.html#sh-2.9
> which starts:
>
> }  Sendmail supports the IDENT protocol as defined in RFC 1413. Although
> }  this enhances identification of the author of an email message ...
>
> That the rest of that text suggests that some of the the people
> responsible for sendmail think as little of that as I think of RMX
> seems like yet another irrelevancy.

The rest of the text refers back to the RFC 1413, what is the point you are 
trying to make?  I think the RFC spells out clearly the security considerations 
involved with IDENT.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Eric D. Williams" <[email-masked]>
Date: Tue, 6 May 2003 16:34:26 -0400

It introduces the possibility for "additional" mis-configuration, as does RMX. 
 The point is that an IP address, I think, SHOULD have only one canonical name.

-e

On Tuesday, May 06, 2003 2:43 PM, Vernon Schryver 
[SMTP:[email-masked]] wrote:
> > I stand corrected.  I do not see that as a best practice (esp. related to
> > secure configuration of an IP).
>
> I don't understand the second sentence.  How is a system's security
> affected by having more than one PTR RRs for an IP address?
>
> I would agree that because many applications and support tools don't
> understand multiple PTR RRs per IP address, it would be unwise to
> build a large scale protocol or application that depends on them being
> widely supported immediately.
>
>

---

From: "Bob Atkinson" <[email-masked]>
Date: Tue, 6 May 2003 14:14:55 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Eric D.
> Williams
> Sent: Tuesday, May 06, 2003 1:34 PM
> To: 'Vernon Schryver'; [email-masked]
> Subject: RE: [Asrg] seeking comments on new RMX article
> 
> It introduces the possibility for "additional" mis-configuration, as
does
> RMX.
>  The point is that an IP address, I think, SHOULD have only one
canonical
> name.

I find this odd: IP addresses with which I am familiar routinely have
many names that resolve to the address: they serve many web domains, for
example, or send and receive mail on behalf of several domains. I don't
understand which of these several domains could reasonably be considered
more equal than others and thus the ONE such canonical name.

	Bob

---

From: "Eric D. Williams" <[email-masked]>
Date: Tue, 6 May 2003 19:42:08 -0400

With respect to rDNS, my practice has been to establish only a single canonical 
name to that addresses reverse map.  I do not see a need to attach more than 
one name.  I don't disagree that an IP may have multiple forward maps to 
accommodate 'web-hosting' but to me reverse maps have little or nothing to do 
with web hosts.  I see utility for rDNS where protocols attempting to validate 
a presented name e.g. myhost.home.net is the expected name at the reverse map, 
i.e.. using ssh, ftp, telnet or smtp.  MTAs SHOULD have and use only a 
canonical name and not an alias, I feel that it is equally appropriate for the 
reverse map of an MTA host.

That's my bugaboo, like I said it is a preference, I thought was a best 
practice as well.  Although obviously it is not a 'rule' of any sort.  Were I 
serving domains in the fashion you present I would most likely have a different 
view as well.

-e

---

From: "Bob Atkinson" <[email-masked]>
Date: Tue, 6 May 2003 17:08:33 -0700

Thanks. Maybe we're agreeing, but I'm still not sure. Maybe it's just
the end of a long day...

If more than one domain (say foo.com and bar.com) can legitimately
originate mail from my address 1.2.3.4, and one attempts to 'validate a
presented name' using rDNS, yet only one name can be established to
which 1.2.3.4 reverse maps, how can it possibly be that at least one of
foo.com or bar.com does not fail to validate? (Aside: Commonly it will
be *neither* that validates, since the rDNS query goes to my ISP, not
me.)

Perhaps you would deny my premise, and insist that each domain wishing
to originate mail have its own unique IP address. If so, that would be a
consistent viewpoint, but, IMHO, not a realistic restriction to impose
(note that no DNS aliases or CNAME records need be involved here).

---------------------
> From: Eric D. Williams [mailto:[email-masked]]

> With respect to rDNS, my practice has been to establish only a single
> canonical name to that addresses reverse map.  I do not see a need to
attach more than one name.  I don't disagree that an IP may have
multiple forward maps to accommodate 'web-hosting' but to me reverse
maps have little or nothing to do with web hosts.  I see utility for
rDNS where protocols attempting to validate a presented name e.g.
myhost.home.net is the expected name at the reverse map, i.e.. using
ssh, ftp, telnet or smtp.  MTAs SHOULD have and use only a canonical
name and not an alias, I feel that it is equally appropriate for the
reverse map of an MTA host.

> practice as well.  Although obviously it is not a 'rule' of any sort.
Were
> I serving domains in the fashion you present I would most likely have
a
> different view as well.

---

From: "Eric D. Williams" <[email-masked]>
Date: Tue, 6 May 2003 21:05:55 -0400

Using RMX my understanding is that the IP of 1.2.3.4 would be associated with 
both foo.com and bar.com however a reverse map RR using my premise would likely 
be:

4   IN   PTR   out-bound-mailhost.infobro.com.

And forward maps in foo and bar would be

foo.com
mail   IN   A   1.2.3.4

bar.com
mail   IN   A   1.2.3.4

I don't think RMX requires any more information in the normal DNS.

foo.com   IN   RMX   ( out-bound-mailhost.infobro.com )
bar.com   IN   RMX   ( out-bound-mailhost.infobro.com )

out-bound-mailhost.infobro.com   IN   APL   ( 1.2.3.4/32 )

-e

---

From: "Eric D. Williams" <[email-masked]>
Date: Tue, 6 May 2003 20:54:31 -0400

Think policy boundary on the home network (firewall).
Think SMTP is SMTP to recieving host from your laptop.
Think mailbox access is web-mail to home office for example.

-e

On Tuesday, May 06, 2003 7:53 PM, Bob Atkinson 
[SMTP:[email-masked]] wrote:
> > Another common case involves people traveling.  If you plug your
> laptop
> > into the network of a hotel or one of your consulting clients, you
> > might prefer to use an envelope and From header address at your home
> > systems instead of [email-masked] or
> [email-masked].
>
> I'd like to understand this scenario better, as at present I am
> confused.
>
> Among my confused thoughts are the following questions: What were the
> steps that led to a mail address and mail server in my hotel room? Which
> part of the hotel's policy forced me into that? Does any hotel actually
> do this? In your understanding, which SMTP server is the STMP client on
> my laptop talking to in order to send it's mail?
>
> I would have expected instead that having got IP connectivity, my mail
> reader on my laptop would have connected back to my normal home (e.g.:
> pop3.mycompany.com/smtp.mycompany.com) and then sent and received mail
> through there as usual, resulting in the normal From headers, etc.
>
> 	Bob
>

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 6 May 2003 20:37:48 -0400

>my laptop talking to in order to send it's mail?

Hotel and travel systems (e.g. T-Mobile in Starbucks) often intercept 
port 25 and send the mail out via their own mail server.  Presumably 
they do this so that they can rate-limit and keep spammers off their 
network. In fact some commercial systems for hotels not only 
intercept port 25, they take a look at what you are trying to connect 
to and create a fake network tailored to your laptop--so you don't 
even have to use DHCP.

Otherwise I'd say SMTP AUTH is a perfectly good solution.  But what 
you're running into is that ISPs spam-prevention systems are getting 
in the way of longer term solutions.

All of which reinforces something I believe more and more as I watch 
th is group.  That what ASRG should be doing is not trying to solve 
the spam problem at all--but rather setting interoperability 
standards so that all of the existing spam solutions don't end up 
creating a crazy quilt mess.
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Eric D. Williams" <[email-masked]>
Date: Wed, 7 May 2003 09:38:24 -0400

On Tuesday, May 06, 2003 8:38 PM, Kee Hinckley [SMTP:[email-masked]] 
wrote:
8<...>8
> creating a crazy quilt mess.

That may be true.  I think that is a valuable goal, though not a requirement.

-e

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 7 May 2003 06:23:55 -0700

>   When you receive a message with an envelope 'from' in a domain, has
> that domain consented to the use of it's name?  Right now, we don't
> know.  With something like RMX, the owners of that domain can make
> their consent explicit.

The opponents of RMX seem to live in a world where there are two choices,
delivering the mail and sending it to the bit bucket.

That is NOT what is being proposed. What is actually being proposed is
a three choice system - Deliver, Spam-Filter and Bit-Bucket.

The reason for this is that we can see that in the near future the
spam filtering criteria are going to escalate like mad. So getting
your mail through will be harder. 

Getting caught in the spam trap will be almost as bad as going to
the bit bucket direct at some stage.

If I have proof a message came from the hotmail servers and I know
that they employ rate limiting the chance that the message is spam
is small. so the message can either be delivered immediately or 
spam filtered with a much lower level of suspicion.

Of course there are circumstances that RMX does not address and
there are a couple of problems with the degree of authentication.
in particular we already have problems with spam senders stealing
unused IP address blocks. RMX could create an incentive to start
DNS spoofing and advertising BGP routes for blocks that are in
use.

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 8 May 2003 05:02:06 -0700

There is a solution to this problem, a VPN.

I don't think it is necessary to insist that RMX solve every problem. It is
a quick fix that will buy some time, not a long term solution.

The answer to the problem lies in the filter behavior. You do not have to
bitbucket every message that does not have the proper headers, you just
assign a big spambayes penalty so that the threshold for bitbucketing is
much lower.

Also you can take other behaviors like not bouncing.

		Phill

> From: Tom Thomson [mailto:[email-masked]]
> Sent: Thursday, May 08, 2003 7:22 AM
> To: Bob Atkinson; [email-masked]
> >> Another common case involves people traveling.  If you 
> plug your laptop
> >I'd like to understand this scenario better, as at present I 
> am confused.
> >
> Two separate questions there.
> 
> 1.  Yes, some hotels provide a mailserver and a guest email 
> acount (for
> example hotels using Neos products).  Often these are send 
> only accounts
> (horrible concept, isn't it).  However, the MUA in these 
> cases is a machine
> owned and managed by the hotel (at least in all cases I'm 
> aware of) and not
> the guest's laptop, and both the content From header and the 
> envelope From
> header will be as Vernon described.
> 
> 2.  Yes, hotels provide internet connectivity for guests 
> laptops.  When they
> do so they usually expect the guest to connect to there normal mail
> provider.  This is a problem with providers that don't do 
> authentication of
> some sort, but not the hotel's problem so they've not much 
> incentive to
> solve it. Some do block port 25 so you have to use their 
> outbound MTA, and
> that writes a suitable Received From header identifying the 
> room, but I
> don't think these systems usually rewrite the envelope From address.
> 
> I haven't seen a case where the envelope From would identify 
> the hotel room
> when the sending MUA is the guest's laptop rather than the 
> hotel's machine,
> but I imagine this situation exists as suggested by Vernon.  
> It's just a
> variant of 2 above where the hotel's MTA does rewrite the 
> envelope From.
> 
> Tom
>