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 room1234(_at_)losangeles(_dot_)merriot(_dot_)com or
guest(_at_)example(_dot_)com(_dot_)
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> cyndi(_at_)hotmail(_dot_)com
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.
- 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.
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?
- for a long time, very few systems will have RMX records, so
upgrade paths are irrelevant.
The upgrade will never happen unless there is a path to it.
- 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.
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
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg