From: Karl Prince
Sent: Sunday, July 04, 2004 5:53 AM
On Sun, 04 Jul 2004 11:08:16 +0100, Graham Murray wrote:
Karl Prince <spf(_dot_)pobox(_at_)princeweb(_dot_)com> writes:
* What I was trying to say (and still struggling to do
eloquently), is that coz of the current state of SMTP, it has
been historically very easy (and cheap) to have vanity domain
email. However as we more to a more secure/trustworthy SMTP
system, this will cease to be the case, and (vanity) domain
owners are likely to have to spend more than just a
registration fee to have their mail accepted.
Why? Surely all that should be necessary is to publish SPF (or MARID)
DNS records that indicate the MTAs which will be sending their mail
and either running their own MTA or using SMTP-AUTH to connect with
the MTA which will send the mail. None of which should cost much and
in many cases will be free.
The context of the original post has been lost on way, which
was about shared MTA's (trustworthy or not), use of SMTP AUTH,
and limiting domain names to nominated accounts.
Thanks for bringing us back to the original question.
To answer Graham's "Why?" above, an SPF record can only state that a given
ISP's MTA can send mail on behalf of a domain. If the ISP is gigantic, that
does not give very much protection to the domain owner. Such an SPF record
allows any customer at the ISP to use that domain name. If we are talking
about Earthlink, that's a lot of people we just gave permission to use our
domain name.
It first seems that the exists mechanism would be able to grant the
necessary per-user permissions. An example SPF record could be
v=spf1 a mx exists:%{s}.remote_users.example.com -all
This doesn't quite get it right as the macro would need to expand to
local-user(_at_)ISP(_dot_) It seems like if we want to give ISP's the ability
to use
SPF to validate a particular local user to use a foreign domain name in
their return-path, From:, Sender:, etc., we would need yet-another-macro
(YAM)tm to describe this. The macro would expand to the user's local
account address. Ideally, there would be another piece of syntax added that
says what username the local account holder is permitted to use at the
foreign domain.
The reason for the second piece of information is that if you log in to the
foreign domain through SMTP AUTH or a VPN tunnel, the foreign domain MSA can
decide what local-part you are allowed to use with that domain. They may or
may not really enforce that, but they _can_ do it, should they cared to. It
makes sense to be able to limit the use of a domain name, as well as a
particular local-part with that domain name, to specific outside users, not
just any user at a particular service.
While this isn't a completely awful idea, it's a pretty awful idea. It
requires at least one YAM (see above) and some additional syntax to describe
the acceptable local-part that a given outside user can claim. Without
this, designating any large ISP as an acceptable sender for your domain does
very little to protect your domain, and does nothing to protect specific
identities at the domain.
Whether an ISP would be able to easily verify if an account
should be allowed to send email from domain a user has
requested is the problem I noted. IMHO the easier and better
(short term) solution is to have the DNS provider provide the
service since they "know" the domain owner, but for this there
will probably be a charge.
For ISP's to provide this service, there need to be an easy
(automagic) way for them to verify the user is authorised to
send email for a domain, whois contact address maybe, though
better have a strong password for that SMTP AUTH. ISPS doing
this would be good, particularly if they did not charge.
I'm coming to the opinion, similar to Karl, that it is not necessarily each
of our God-given rights to register a domain and then forge email from a
local ISP just to save us a little bit of money. We may be coming to a time
when we register a domain, we have to pay someone to host email for the
domain, if that's a service we want, just like we have to pay someone to
host a web site for the domain, if we want that service. That being said,
it is possible that local ISP's could do this for a one-time charge, as it
is primarily a setup issue and not an ongoing operating cost.
Some ISP's might look at it differently, saying, "we give you ten email
accounts with your current service, so hosting your domain email with ten
more accounts will cost you xxx/month". Since it goes over the same local
line, it shouldn't have to cost a lot. If they try to charge too much, they
will ultimately suffer. An alternative would be to host the email for your
vanity domain at another outside service that provides SMTP AUTH access.
Yes, you will be paying for internet access from one provider and email
hosting from another, but that's really not any different from the way web
site hosting is commonly handled today.
--
Seth Goodman