spf-discuss
[Top] [All Lists]

Re: Architectural issues with the SPF specification

2005-01-04 21:16:42
--Julian Mehnle <bulk(_at_)mehnle(_dot_)net> wrote:

Julian Mehnle wrote:
I have now finally managed to read through the whole spec.  Here are my
suggestions [...]

Also, I have the following additional suggestions:

1. Suggest "HELO domain" instead of "HELO mx.domain".

Section 3.1 ("Publishing") mentions that the zone cut feature can be used
to avoid having to publish additional SPF records for all MX names
(mx.example.org), but that this requires additional DNS lookups.  However,
if the MTA(s) can use the domain name (example.org) instead of the MX name
(mx.example.org) in its HELO/EHLO commands, additional SPF records can be
saved without requiring additional lookups.  This is the case if
example.org points to the same IP address(es) in DNS as mx.example.org,
which applies to many small sites.  I think this would be worth a mention
in 3.1.


I am not sure what the prior RFCs have to say about this specifically, but my general impression is that the HELO name should be a hostname. My understanding was that the HELO name should identify the specific server.

Before we start encouraging people to change their mailservers to HELO with another domain name, we should probably sort of "run it up the flagpole and see who salutes" so to speak. Maybe float the idea on some other anti-spam lists like spam-L or spamtools. Also it would be cool to see some specific data on how easy/hard it is to change the HELO name in certain web servers.

If the text we come up with doesn't actually recommend this, but just mentions that it's possible, then that's probably the safest course and we don't have to worry about whether it's a good idea... we're just saying that if people choose to do that, SPF supports it. (I think this is probably what you meant)


2. HELO checking and MAIL FROM checking.

The current spec lacks a clear vision of the relation between HELO and
MAIL FROM identities.  This is partly due to the historical fuzzy
definition of the HELO identity.  We have two options:

  * We can either leave it at that, which would leave those HELO checks in
    a somewhat pointless limbo: HELO is only checked if MAIL FROM is <>.
    This is the current and traditional vision of SPF.  This makes the
    HELO identity more or less irrelevant in the general case, because
    like in RFC 821 and 2821, it isn't used for anything meaningful
    (except for SPF checks in the "bastard" MAIL FROM: <> case).

  * Or we can describe a clear vision to actually make HELO checks useful:
    HELO is always checked, regardless whether MAIL FROM is <>.
    This is my preferred vision.  It gives the combined HELO+MAIL FROM SPF
    checking procedure a modular structure because we can say that
    MAIL FROM checking relies on prior HELO checking.  Thus the HELO
    identity has a clearly defined meaning.

Both options don't really differ in how HELO is being used by SPF, but the
second one gives a clear vision of what HELO means and, like MAIL FROM,
properly protects it from being forged.


Agreed. I like the second one better, though we shouldn't be heavy-handed about saying "HELO should be used for X"... maybe more passive like "If HELO is a domain name with an SPF record, it can be checked in this way." As in, we generally expect it to be used in a certain way, but we're not mandating it.

If what we say here is a conflict with RFC 2821, that's OK, but we should say explicitly what provisions of 2821 are intentionally deprecated.

Basically I would like the spec to pave the way for HELO checking, but not specifically require it. So I would stop short of saying that the MAIL FROM check depends on the HELO check, but we could say that if HELO check is to be performed, it should be done first. I don't want to tell people "you must check HELO" but we can trust that they will if it seems to work for most other people. :)


--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>