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

From: Scott Nelson <[email-masked]>
Date: Tue, 06 May 2003 00:18:40 -0700

At 07:48 PM 5/5/03 -0600, Vernon Schryver wrote:
>> From: David Maxwell <[email-masked]>
>
>> ...
>> You have one more piece of information - "The sending domain is valid,
>> correct, and claims that this host is a valid host to source mail."
>>
>> The current SpamAssassin applies negative scores for certain patterns.
>> Unfortunately, most of the patterns it uses today can be forged by
>> spammers, making them useless. If the RMX 'bit' appears as a header
>> inserted by my local MTA, my filter can give it a negative score, with
>> confidence.
>
>That is mistaken.  Spammers can continue to use Hotmail and Yahoo drop
>boxes and to forge AOL's domain name while abusing open proxies on
>large dynamically addressed cable-modem and DSL networks that have at
>least one AOL, Hotmail, or Yahoo user.  
>

With RMX, if a spammer finds an open relay on AOL then they can 
forge email that looks like it comes from AOL.

Compare that with the non-RMX case where they can forge the domain
example.com and send it through that same relay in AOL.

In the first case, we all pay for receiving the spam, 
AOL pays for sending the spam, 
AOL must deal with complaints about the IP in their network sending spam, 
AOL must deal with complaints about their domain is sending spam, 
and AOL must handle all the bounces that the spam run generates.  

In the second case, we all pay for receiving the spam, 
AOL pays for sending the spam, 
AOL must deal with complaints because their IP is sending spam,
but example.com has to deal with the complaints about their domain 
sending spam, 
and example.com must handle all the bounces that the spam run generates.  

If example.com is an IDSN line, the bounces alone might be enough to 
take out their network.  But they can't do anything until AOL 
decides to fix the problem.  Example.com can't do anything about it.

So to me this looks like a win for RMX, not a tie.

The cynical might point out that it looks better for AOL in the
second case, so why would they adopt RMX?  Note though, that
in case two AOL wouldn't fair any worse if they had an RMX record,
and example.com would have done a lot better if example.com did.

>Because those networks are
>dynamically addressed, an ISP with users on networks that allows third
>party sending (including AOL, Yahoo, and Hotmail) must set their RMX
>'bits' to say "authorized" for all addresses in such a network.  Thus,
>the hardest to filter spam can have good RMX bits.
>

They could set their policy anyway they want,
but I think it's more likely that they would provide relays that
only their users could use, and set their RMX records to point
to only those relays.  The clueless wouldn't be able to handle
sending mail directly, and there won't be that many who want 
to send as example@AOL from within the AOL IP space, 
but refuse to use AOL relays to do that.  Some perhaps,
but I doubt AOL would care that much about them.

>The only fix is to prohibit sending from any mail systems but those
>of the ISP that owns the IP address.  However, if you want to enforce
>that rule, you don't need any new RMX or other bits.  You need only
>compare reverse DNS and envelope sender domain names.  
>
Doesn't follow.

>(Yes, reverse DNS can be faked, but that can be reasonably reliably 
> detected by doing an extra forward lookup of the reverse name.)
>(Yes, in some
>cases you must do a little more than just comparing the PTR and A RRs,
>such as fetching all PTR RRs or all A RRs for the PTR name.)
>

Reverse DNS is controlled by the IP.
If they have an rDNS, you would do about as well by skipping
the rDNS and using the HELO to do a forward look up.
Of course, having rDNS is also a sign of clue, 
and many spammers are lacking in that which makes the mere presence
of rDNS a good test.

>
>(This has nothing to do with my claim that to keep their users, Yahoo,
>Hotmail, and AOL must mark every IP address on the net as "authorized.")
>
They don't have to, but they might want to.
(Though why they would go to the trouble of providing one that's
 pointless instead of just not supporting it is a bit of a reach IMO.)

I don't see it in AOL's case, since they have nothing to lose by
continuing to provide mail relays for their customers, 
but Hotmail might since they don't provide them.
Then again, they might prefer it if people had to use their web
interface to send email.  But hey - their domain, their choice.
Setting a broad RMX means you have to deal with more complaints
and more bounces - they might think it's worth it.

>
>>                                                          When I say
>> _eliminate_, I mean users employing RMX checks will not have to read
>> these spams anymore, and if deployment becomes widespread enough,
>> spammers won't bother sending them anymore.
>
>How widespread enough is enough?  My guess is 80%, but if you prefer
>90% or 50%, I won't argue.  How long will it take to reach that level?
>If it is 10 years, will your ISP deploy this decade?  If 1,000,000
>users get it in the next year, would it be worthwhile for you to check
>RMX bits?  1,000,000 users are about 0.2% of the Internet, so only
>0.2% of legitimate mail would have it.
>

I imagine the amount of time it takes to deploy would depend a lot
on how much real benefit and real cost is associated.
Neither the RMX proposal or the DMP proposal is workable without
some changes to DNS, and DNS changes tend to be slow in coming.
(Didn't Vixie start championing SRV records over 5 years ago?)

When it comes to sending, I think David's premise is flawed.
When new technology has come out in the past,
spammers seem to adapt by sending just as much spam the old way, 
and also sending more a new way that beats the technology.
I think it's more likely spammers will continue to send forged spams,
even if 90% of internet automatically blocks them.

>> ...
>> It eliminates some types of spam. If we had an applicable method that
>> eliminated each type of spam, should we not apply them all - and instead
>> look for a single solution?
>
>Again, how does it eliminate any spam?  In practice, what spam would
>it eliminate that does not already have a mismatch between reverse
>DNS and envelope sender domain?
>

I think a better question is:
"Does it have a better false positive or false negative rate than
 reverse DNS and envelope sender domain?"

And I think it would have a better false positive rate /and/ a better 
false negative rate then reverse DNS + envelope sender domain.
Lots of spam has forged headers and envelopes.  Some spam even
has forged rDNS.  Both would catch the first part, but only
RMX would catch the last.

>
>> ...
>> Today, as a domain owner, I have no way of telling people 'Mail from my
>> domain will only come from these IPs. Any other source is a forgery.'
>
>Wouldn't be simpler to tell everyone to compare your sender domain name
>with your reverse DNS?
>

rDNS does not support multiple domains.
with rDNS, if you have two vanity domains you need two IP addresses.
if you run an email service you might host hundreds of domains
per IP.  So, yes, if you're one of those people it's a lot simpler,
because you couldn't support rDNS at all.

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

---

From: Daniel Feenberg <[email-masked]>
Date: Tue, 6 May 2003 07:44:52 -0400 (EDT)

> because you couldn't support rDNS at all.

Is this right? Is there some reason many different MAIL FROM: host
names couldn't point to a single SMTP host? 

I think the receiving host looks up the domain name of the FROM address to
check that the connecting host is among the RMX records returned. It
doesn't look up the connecting host to see if the FROM address is listed.

Why has Vixie's similar proposal gotten no discussion here? He wanted to
overload existing MX records with the same information. In effect, 
receivers would accept mail only from hosts with MX records matching the
MAIL FROM address. If a sending domain wished to send from a host but
not receive mail to it, the MX record could be given a very low priority.
A minor advantage here is that BIND doesn't need to be changed. A larger
advantage is that many sites already send and receive from the same host,
so there is a "start up capital" of many millions of pre-configured
sites.

If the "very low priority" is specified in the standard, then there isn't
even any difficulty telling if an MX record is specifically for
verification purposes or not.

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 6 May 2003 08:02:44 -0600 (MDT)

> From: Scott Nelson <[email-masked]>

> and many spammers are lacking in that which makes the mere presence

The RMX check as I understand it is intended to ask the people who own
the envelope sender domain name if the IP address of the SMTP client is
authorized to send mail with that sender name.  If the HELO value matches
the sender name, and if one of the IP addresses of the HELO value is that
of the SMTP client, then the SMTP client is authorized.

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.

> RMX would catch the last.

How do you "forge" reverse DNS?   My dictionary says that forgery has
something to do being false.  If you check that one of the IP addresses
for the reverse DNS name is IP address whose reverse DNS name you
looked up, then reverse DNS forgery is practically impossible for
spam.  (Of course, without DNSSEC, there are other attacks, but they
could also be used against the RMX bits.)

> with rDNS, if you have two vanity domains you need two IP addresses.

That seems to be based on the mistaken notion that there can be only
a single PTR RR per IP address.

> because you couldn't support rDNS at all.

That's mistaken.  If one of your IP addresses is used for hundreds of
domain names, you would not want hundreds of PTR RRs.  (I've known of
ISPs that hosted thousands (1000s) of domain names per IP address.
That forced the code of my UNIX vendor employer at the time to be a
lot smarter than the classic BSD TCP code when mapping names to
interfaces.)  Instead, as I tried to say but was doubtless not clear,
when to the simple comparision of PTR RR values to STMP envelope sender
domain name fails, SMTP servers might be satisfied if one of the MX
RRs for the sender domain contains the SMTP client IP address.

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

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 6 May 2003 08:37:53 -0600 (MDT)

> From: Daniel Feenberg <[email-masked]>

> so there is a "start up capital" of many millions of pre-configured

That's clearly the way to implement RMX bits.  However, it suffers
smaller but still serious versions of the problems that come with
other RMX ideas.  One is the new limitation that mail with any given
sender domain name can only be sent from a pre-determined handful of
computers.  That limitation conflicts with the business models of many
ISPs and the desires of many users.

(Please, everyone, don't treat me to yet another recitation of how
changes in the Internet require that the rules change unless you are
Dictator of the Internet and have the netcops to enforce new rules.
If the IETF/IRTF had any netcops, it would have long since enforced
rules on more important issues than spam.)

> verification purposes or not.

I think part of the idea is that you don't need to standardize "very
low priority."  In practice, thre are only two cases.  Either the host
answers port 25 and so the MX record is perfectly valid, or it doesn't,
and no harm is done.  The worst effects of an MX record pointing to
a host that doesn't answer port 25 is an immediate ICMP Port Unreachable
message telling the SMTP client port 25 isn't working.  Since these
bogus MX records would be last, they would only slightly slow down the
SMTP failure case of no working MX server.

---

From: Hadmut Danisch <[email-masked]>
Date: Tue, 6 May 2003 16:58:54 +0200

On Tue, May 06, 2003 at 08:02:44AM -0600, Vernon Schryver wrote:
> 
> If the HELO value matches

RMX has nothing, absolutely nothing to do with the HELO value.

You simply don't know what you are talking about, but that
doesn't keep you from flaming. 

Hadmut

---

From: Mike Rubel <[email-masked]>
Date: Tue, 6 May 2003 09:43:54 -0700 (PDT)

> of the SMTP client, then the SMTP client is authorized.

Vernon,

This is not quite how RMX works; perhaps our disagreement stems from a
simple miscommunication.

Won't you please take a look at the page?

	http://www.mikerubel.org/computers/rmx_records/

Thanks,
Mike

---

From: Steven F Siirila <[email-masked]>
Date: Tue, 6 May 2003 12:02:32 -0500

> the rDNS and using the HELO to do a forward look up.

As mentioned previously on this list, a spammer has control over the EHLO
parameter for open proxies, but has no control over the originating IP
address.  So there is a difference.

> and many spammers are lacking in that which makes the mere presence

We are finding rDNS checks to be more and more useful over the past 9 months
as more and more real MTAs are getting "proper" rDNS RRs.  What makes these
checks useful is that the spammer using open proxies and the like has no
control over rDNS configuration, only over the SMTP sessions they create.
We are finding that a lot of sites do not bother setting up rDNS for the
many client workstations they are responsible for.  This makes those very
workstations unable to be abused by spammers (at least for sending to sites
who check rDNS, such as ours).
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 6 May 2003 11:06:47 -0600 (MDT)

> From: Mike Rubel <[email-masked]>

> 	http://www.mikerubel.org/computers/rmx_records/

Yes, I did not realize that RMX was based on the notion that I've
previously characterized as stuffing the Internet back into the old
big BBS model favored by AOL.  Forcing users to pick an ISP and stick
to it is characteristic of a BBS or bulletin board system.  It has
many attractions for some ISPs but not for others.  Many users were
happy with BBS's, but some weren't and would not be.

Have you considered Paul Vixie's version of RMX?  Given the premise
of requiring users to have a "home sending MTA," why isn't Paul's the
obvious and only reasonable instantiation of the idea?  What do new
RRs buy that do not come from MX records, except a lot of problems?

---

From: Michael Rubel <[email-masked]>
Date: Tue, 6 May 2003 11:46:22 -0700 (PDT)

VS> Yes, I did not realize that RMX was based on the notion that I've
VS> previously characterized as stuffing the Internet back into the old
VS> big BBS model favored by AOL.  Forcing users to pick an ISP and stick
VS> to it is characteristic of a BBS or bulletin board system.  It has
VS> many attractions for some ISPs but not for others.  Many users were
VS> happy with BBS's, but some weren't and would not be.

Vernon,

Every email now should have a From: header, with a sender at a real,
existing domain.  RMX doesn't change that.  If you have a mail server
separate from your ISP, you probably use POP or IMAP to retrieve your
messages from it; your ISP merely provides the connection.  You could also
configure the machine to act as an SMTP server, in which case your outbound
mail would also pass through it.  Again, your ISP merely provides the
connection.  The RMX record for that server would be its IP address, /32.

If you have multiple accounts at many different domains, your ISP would
carry the messages to and from each one, instead of merely from each one and
to wherever you happen to be sending mail.

The effect of RMX is to give domain owners a way to prevent third parties
from making email appear to come from them.  It has no bearing on who owns
or operate domains.  Nor does it, so far as I can tell, "forc[e] users to
pick an ISP and stick to it."  Any ISP capable of getting the packets to and
from your mail servers will do.

VS> Have you considered Paul Vixie's version of RMX?  Given the premise
VS> of requiring users to have a "home sending MTA," why isn't Paul's the
VS> obvious and only reasonable instantiation of the idea?  What do new
VS> RRs buy that do not come from MX records, except a lot of problems?

If I understand his proposal correctly (and with all due respect to Paul),
the main problem is that a lot of domains don't obey this convention yet,
and you have no way to know which ones do and which ones don't.  So you
can't make very strong decisions based on it.  That's why you accept email
from [email-masked], even if it obviously arrives from a third-party IP
address.

RMX records give us an upgrade path--a domain declares that it now conforms
to this convention by setting up an RMX records.

Mike

---

From: Hadmut Danisch <[email-masked]>
Date: Tue, 6 May 2003 22:48:25 +0200

On Tue, May 06, 2003 at 03:56:40PM -0400, Daniel Feenberg wrote:
>
> It would probably be usefull if you posted a few sentences to go
> over exactly what the validation steps are for a site using RMX
> to control incoming mail. 

OK.

Let's go through an example (not yet implemented)

1. Authorized mail
  Imagine I am sending you an email.

  My MTA opens an SMTP connection to your
  MTA (where the MX of your domain points to). Your MTA
  sees an SMTP connection from 213.133.101.23. Nothing
  hapens so far. HELO or EHLO doesn't matter.

  Now my MTA issues the SMTP command

    MAIL FROM: <[email-masked]>

  and waits for the reply code of your MTA.
  This is where your MTA performs the RMX lookup:

  The sender address [email-masked] has the
  domain part danisch.de. So the RMX record for danisch.de 
  is queried. 

  danisch.de IN RMX  ( relays.rackland.de  relays.somecompany.com )

  because I might use the relay machines of Rackland and SomeCompany
  to deliver mail. But I do not want to update my zone table every
  time Rackland and Somecompany change their IP addresses. So
  it is the task of Rackland's and SomeCompany's administrations
  to keep the APL records below up to date.

  In a second step, the APL records are fetched:

  relays.rackland.de    IN APL ( 213.133.101.23/32 )
  relays.somecompany.de IN APL ( ...some addresses )

  After the first APL record the check is finished because it
  positively covers the IP address where the SMTP connection came
  from.

  -> your MTA learned that my MTA with that particular IP address
     was authorized to use danisch.de as a sender domain.

2. Unauthorized mail / Spam

   Now a second SMTP connection is opened to your MTA, 
   this time from 62.226.51.34. Again, nothing happens so 
   far. 

   Now the sending MTA issues the SMTP command
 
      MAIL FROM: <[email-masked]>

   (which is unauthorized)

   Now your MTA fetches the RMX and APL records as described above.
   But these APL records do not cover the IP address 62.226.51.34

   -> Now your MTA learned that the message came from an IP 
      address that was not authorized to send

   -> It's up to you and your local rule set what to do with it,
     whether to reject, drop, tag, run through a content filter or 
     whatever.

Should be enough to understand the basic principle.
(For easier reading I simplified the APL syntax a little bit)

Hadmut

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 6 May 2003 17:14:14 -0600 (MDT)

> From: Michael Rubel <[email-masked]>

> VS> big BBS model favored by AOL. ...

> from making email appear to come from them. 

That is the intended effect of RMX, but it is not the only effect.

>                                              It has no bearing on who owns

That is mistaken, unless you assume big-BBS model in which individual
computers are dumb terminals connected to a single big BBS style ISP.
Whether you other raw connectivity ISPs or a dialup modem through the
telephone system to reach the big BBS ISP is irrelevant to the big
BBS style of Internet you posit.

The common mode that you would outlaw is where people send from one
IP address with an unrelated envelope Mail_From value.  For example,
many people configure their computers at work to send with a envelope
and header value of a mailbox at a free provider.  They do this to
avoid entanglements between their words and their employer.  Because
are not named Bill Gates, they can't get Hotmail's RMX data to authorize
their sending IP address, if they know it, which may be literally
impossible because of NAT.

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].

> to this convention by setting up an RMX records.

There are several problems with that reasoning.  
  - it assumes that Hotmail will ever have RMX records.  Because having
      RMX records would drive away a significant number of Hotmail's
      users, you'll always have decide to accept mail from [email-masked]
      
  - it assumes that you can't already decide to accept mail with Hotmail
      sender addresses only if it comes from a Hotmail SMTP client.  In
      fact it is common to check that the source of Hotmail mail is
      Hotmail.

  - for a long time, very few systems will have RMX records, so
      upgrade paths are irrelevant.

  - if you want to mark systems that follow Paul's convention so that
      you know which don't, you could pick a large MX preference that
      its extremely unlikely to be used for anything today.  For
      example, I bet that among the millions of MX RRs today, none
      has the preference 65391.

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 06 May 2003 23:04:48 -0400

Vernon Schryver <[email-masked]> wrote:
> IP address with an unrelated envelope Mail_From value.

  No one has used the word "outlaw".  The recipient MTA would decide
what to do with an SMTP session when the originator lies to it.
Maybe the IETF ends up with an RFC saying such lies MUST NOT occur,
but who really pays attention to RFC requirements?

> systems instead of [email-masked] or [email-masked].

  Despite Dave Crockers assertions to the contrary, other solutions
for roaming users exist, than lying in SMTP transactions.  Even his
comments against webmail "not scaling" are trivially and obviously
wrong: Hotmail.  It has tens of millions, and dare I say, approaching
100 million users.

  That existing solution address ALL of the concerns with roaming
users requiring email access (but NOT necessarily SMTP), and with
scalability to 100's of millions of users.  The fact that you,
personally, probably hate web mail is your issue, and doesn't negate
the underlying truth of the argument for changing the behaviour of
roaming users.

  Alan DeKok.

---

From: Mike Rubel <[email-masked]>
Date: Tue, 6 May 2003 22:22:22 -0700 (PDT)

MR> It has no bearing on who owns or operate domains.  Nor does it, so far
MR> as I can tell, "forc[e] users to pick an ISP and stick to it."  Any ISP
MR> capable of getting the packets to and from your mail servers will do.

VS> That is mistaken, unless you assume big-BBS model in which individual
VS> computers are dumb terminals connected to a single big BBS style ISP.
VS> Whether you other raw connectivity ISPs or a dialup modem through the
VS> telephone system to reach the big BBS ISP is irrelevant to the big
VS> BBS style of Internet you posit.

Vernon,

Do dialup or traveling users run their own MTA's over the dialup line?

Nope--they have remote, permanent servers, which they access via POP or
IMAP.  Somewhere, somehow, they rely on machines that are listening
24/7.  I have such a machine myself.  Call it "BBS-style" if you like,
but it's a present-day fact.

So why shouldn't users send their outgoing mail through specific servers
too, instead of sending the mail directly?

RMX wouldn't make the world any more "bbs-style" than it is now.

VS> The common mode that you would outlaw is where people send from one IP
VS> address with an unrelated envelope Mail_From value.  For example, many
VS> people configure their computers at work to send with a envelope and
VS> header value of a mailbox at a free provider.

Nobody's outlawing anything.  If Hotmail wants people to stop forging
their name on mail, then yes, they need to make sure that remote users
send via their mail servers.  They have a wide variety of commonly-used
avenues for implementing this.  Their webmail users don't have to change
anything.  If hotmail admins still want people to be able to send
hotmail from other machines, they can provide smtp-auth service.  How
does this become a problem?

VS> Another common case involves people traveling.  If you plug your laptop
VS> into the network of a hotel or one of your consulting clients, you
VS> might prefer to use an envelope and From header address at your home
VS> systems instead of [email-masked] or [email-masked].

So they send the mail through their own office's mail servers.  Again,
no problem.

VS> There are several problems with that reasoning.  
VS>   - it assumes that Hotmail will ever have RMX records.  Because 
VS>     having RMX records would drive away a significant number of 
VS>     Hotmail's users, you'll always have decide to accept mail from 
VS>     [email-masked]

Hotmail has a strong incentive to adopt RMX records--it would give them
the ability to prevent spammers to send mail claiming to come from
hotmail.com.  Which means potential recipients of hotmail.com mail would
stop thinking they're the source of all the world's spam.

I tend to disagree with the implication that having RMX would drive away 
any significant number of hotmail users.  Most of them simply access the 
webmail interface; since hotmail does not forward, they need to use it to 
read their email anyway.

>       fact it is common to check that the source of Hotmail mail is

Sure, you can search on the web to find what hotmail.com's outgoing mail
servers are, and set up special filters on your system to only accept mail
from hotmail.com provided it arrives from one of those.  The system works
for hotmail.com--and only hotmail.com--until they change the IP addresses
of their mail servers, at which time they seem unlikely to inform you.

Why not just use RMX, which automates all of this?

>       upgrade paths are irrelevant.

The upgrade will never happen unless there is a path to it.

>       has the preference 65391.

This is a reasonable alternative, but isn't it simpler to post RMX records
instead?  Rather than introducing a new special case in an existing RR,
you introduce an RR for that purpose.

Mike

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 07 May 2003 02:35:19 -0400

Err, Mike hate to break this to you, but I do have travel and I do operate 
my own MTA over the dialup. It's not as uncommon as you think.

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 7 May 2003 07:47:57 -0600 (MDT)

> but it's a present-day fact.

That is a common mode, but not the only one.  Some travelers and
certainly some diaup users run MTAs over dialup lines.

> send via their mail servers.

Perhaps my use of "outlaw" was a bad choice.  I meant "practically
prohibit" instead of anything about laws.  Isn't the intent of the
RMX proposal to practically prohibit using a domain name other that
of the reverse DNS name or a few other special cases?

Your use of "forge" is clearly a bad choice.  "Forgery" is about
fraud.  See http://www.m-w.com/cgi-bin/dictionary?va=forgery
While some uses of Hotmail sender addresses are "forged," a substantial
number, even in spam, are not.  It is not "forgery" to use one of your
Hotmail mailboxes as a sender value no matter from where you send the
message.

>                               They have a wide variety of commonly-used

In practice, I think it would be impossible for Hotmail to provide
SMTP-AUTH.  First is that the problems of managing the authenticating
shared secrets for millions of users with an incredibly high "churn"
rate would be killers.  Second, many Hotmail users could not use
SMTP-AUTH because SMTP-AUTH uses port 25 which is more commonly filtered
for users likely to pick a free provider than others.

Yes, when port 25 is filtered, running your own out-going MTA also
doesn't work,  There is also SUBMIT which uses port 587.

> So they send the mail through their own office's mail servers.  Again,

That's a problem or not depending on how they normally send mail.

> stop thinking they're the source of all the world's spam.

How do you know that incentive is strong for Hotmail?  How do you know
it is stronger than the prospect of driving away at least some users?

> webmail interface; since hotmail does not forward, they need to use it to 

Most of the people I know who use Hotmail return addresses do not
use Hotmail's systems to send mail.

> of their mail servers, at which time they seem unlikely to inform you.

That is wrong.  The common procedure has nothing to do with web
searching but is comparing the reverse DNS name of the STMP client
with the envelope sender domain.  That works for many and probably
most major free providers as a sort of self-fullfilling prophecy.
Many people who might use the RMX have imposed this check on mail from
major free providers for many years.

> Why not just use RMX, which automates all of this?

Because the reverse DNS check already automates it?

> you introduce an RR for that purpose.

That seems clear and unambiguous, but I can't believe I understand it.
Do you really mean to claim that creating a new RR type is not vastly
more difficult than special casing an unused MX preference but easier?

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 07 May 2003 13:20:35 -0400

> of the reverse DNS name or a few other special cases?

  No.

  It's intent is that MTA recipients can choose to "qualify"
(i.e. filter or prohibit) mail from certain IP's, when that mail
appears to be forged.  Your objections to RMX appear to be based on a
refusal to change your network behaviour, and on your insistence that
everyone else must accept that behaviour.

  Even with RMX, you are perfectly free to ignore it's
recommendations.  What's got you upset, I believe, is the thought of
others discarding your messages which are not compliant to a standard
you don't support.  My response is "c'est la vie."

> fraud.

  So how I tell the difference between a spam sent from a dial-up,
which is allegedly from you, and a non-spam message sent by you from a
neighbouring dial-up?

  In your world, I don't.  (Barring PGP, S/MIME, etc.) So my incentive
is to delete all such apparent forgeries as unverifiable.

> rate would be killers.

  That's really for Hotmail to determine, isn't it?

> Second, many Hotmail users could not use SMTP-AUTH because SMTP-AUTH
> uses port 25 which is more commonly filtered for users likely to
> pick a free provider than others.

  So ASRG needs a BCP document, saying filtering port 25 is stupid,
and unhelpful.  Will you put your support behing such a document?

  Alan DeKok.

---

From: "Tom Thomson" <[email-masked]>
Date: Wed, 7 May 2003 19:59:25 +0100

Vernon Schryver wrote:-

>of the SMTP client, then the SMTP client is authorized.

So you are implyng an SMTP protocol change: the HELO line must specify a
domain name. If you are going to assume changes like that in your replies to
other peoples proposals, lets see your properly worked out proposal
containing all such changes.

When you write it up (if ever) please remember to note that an MTA acting as
sender for several domains would have to terminate its connection and
reconnect with a new HELO each time a mail item isn't from the same domain
as the previous item - this may be a significant operational change for some
providers. (I wonder why Postel took this particular <host> parameter of
helo out when he upgraded RFC788 to RFC821. Could it have been to cater for
MTAs serving multiple domains, I wonder?)

>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).

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). Maybe you think
that you can adapt your idea to use MX records - but I have news for you
buddy, outbound MTAs are often not inbound MTAs so they won't have MX
records.

To me, what you are describing is a half-baked attempt to do what rMX would
do by using mechanisms that are just not capable of doing it.

Tom

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 7 May 2003 14:33:55 -0600 (MDT)

> From: "Tom Thomson" <[email-masked]>

> When you write it up (if ever)

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?

Please also consider the possibility that since I do not favor RMX,
I also do not favor this check.  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.

My point was that those who want to make the RMX check can achieve
about the same effect by by checking data that is already present,
standardized, and requires no new protocols or actions by 80% of the
Internet.  Most mail already satisfies such a check, while it would
be many years if ever before a significant amount of mail would meet
a check involving a new DNS RR.  This check is already well understood
by people familiar with dealing with spam.  It is common among the
MTAs of those who prefer not receiving spam to failing to receive
legitimate mail; it causes significant false positives.

>                                please remember to note that an MTA acting as

That change does some to make it easier to compare the HELO domain
name against the sender domain.  However, it might also only reflect
the general jargon drift from "host" or "host name" to "domain" or
"domain name."  In IETF standard language, "domain" or "domain name"
can refer to something with an IP address and so can be a "host name."

> cause quite an upheaval, probably do more economic damage than all the

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.

> 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.

>                                                            Maybe you think

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.

---

From: "Tom Thomson" <[email-masked]>
Date: Tue, 13 May 2003 19:27:59 +0100

> already did?  Or have I misunderstood section 4.1.1.1 of RFC 2821 and

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

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).

> 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.

> 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 [email-masked] 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 [email-masked] 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.

> 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