I'm doubtful that changing the ESMTP protocol will fly -- there are
still lots of people using SMTP and it isn't clear how quickly the
firewall vendors will change to incorporate the new command. On the
other hand, it does have simplicity and cleanness on it's side.
I think that the argument for using HTTP is fairly persuasive. In
particular, I can see a mechanism 'http' which takes a URL as an
argument. Thus we could do:
http://www.{%d}/cgi-bin/spf.cgi?sender=%{U}&ip=%{I}
This could either return "v=spf1 +all" or "v=spf1 -all" depending on
whether the operation was allowed. I'm convinced that we would find a
crop of people implementing these little CGI scripts that implemented
arbitrary policies. This is similar to the ESMTP approach outlined by Dan.
Philip
p.s. My ISP does not permit outbound port 25 connections except to their
mail server. This means that I would not be able to do SPF checking if
the only option was the ESMTP extension. I would have to rely on their
mail server to do it for me....... It would also mean that if my
machine at home (which is my mail server) goes down (or my ISP cuts me
off), then I would not be able to *send* mail via another path. With
regular SPF, I could change my DNS record (hosted by zoneedit) and then
send mail from anywhere.
Dan Boresjo wrote:
On Saturday 22 November 2003 3:08 am, Jasper Wallace wrote:
Personaly if we're going use more that one underlying protocol for SPF then
the non-dns protocol should be SMTP, as someone else proviously proposed
I don't recall the previous posting, so forgive me if am repeating stuff that
has been said before. Using SMTP _only_ (no DNS extras at all) was my first
thought on the issue of sender authentication.
I'm thinking that whatever daemon is running on port 25 of an MX is the
'official contact' for that domain's SMTP operations, and it makes sense to
ask it about who is permitted to send mail. Why not just create an ESMTP
extension for sender repudiation?
The simplest implementation would be a simple 'oracle'. If we were to call the
extension 'XSPF' (for now) and have the grammar:
'XSPF' <SP> (SENDER-HOSTNAME|SENDER_IP) <SP> DOMAIN <SP> LOCALPART
and reponse of the form:
250 <SP> ('ALLOW'|'DENY') <SP> 'FOR' <SP> TTL-VALUE <SP> 'SECONDS' [<SP> 'FOR
ALL']
Where the option 'FOR ALL' in the response means the response is valid for all
localparts in the domain. The rest should be obvious...
This approach has the benfit of:
1. Being extremely simple, hiding the complexity in the ESMTP server
implmentation rather than in the protocol itself.
2. It is easier to get an ESMTP extension registered (I think)
3. It is a postmaster-to-postmaster solution that does not require cooperation
with other administrative roles. It's the postmaster who is at the sharp end
of the spam problem after all.
The downsides:
4. ESMTP conversations use more bandwidth than DNS over UDP.
5. DNS already has a caching infratsructure that is tried and tested. The
requirements in this area for an XSPF oracle system requires some analysis.
6. Although open-source ESMTP servers could easy be patched to support this
and a rollout there could be pretty quick, many domains still use proprietary
mail servers. These are unlikely to adopt quickly and if packaged as a
feature upgrade with a price tag then things will be slower still.
- Dan
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.6.txt
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.6.txt
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡