John Leslie wrote:
[CSV] didn't help retrieving the responsible domain, though.
CSV intended to use the EHLO string _as_ the responsible domain, even
though it might be one of several subdomains under a single management.
Large organizations are often partitioned into (proper) subdomains,
more or less independent from one another. OTOH single mailout hosts
names may also be considered a (degenerate) subdomain.
Furthermore, it didn't do ranges, thus making it laborious to deny
sending to a bunch of hosts.
I agree it didn't "do ranges", since it seemed appropriate to allow
separate reputations for separate EHLO names.
Interesting. However, it is useless to separate reputation of
different EHLO names belonging to an array of mailout hosts where a
specific one is chosen based on traffic optimization and may even
change on retries.
AFAIK, all discussions eventually reach the conclusion that the
receiving server does not know which domain administers the client
MTA.
CSV was intended to address exactly that problem. We felt that the
vast majority of domains _could_ get by with half a dozen IP addresses
returned by a A)ddress record, and that for those that couldn't, the
ability to have separable reputations was an _advantage_. For a
reputation service, more than one reputation record per domain actively
sending (reasonable) email seemed simple enough.
OTOH, it is more difficult to track subdomains. A spammer can easily
add new names at incredible rates. What about DKIM's distinction
between domain (d) and identity (i)? As clever as DKIM may bee, I
never noticed mail messages altered in transit, and would be curious
to know how many filter look at its signature headers for the sole
purpose of extracting the affiliation.
I agree that "affiliation" was not the best choice of words in
draft-ietf-marid-csv-csa-02. "Affiliation" should be multi-valued,
with an individual sending MTA able to affiliate with multiple
entities.
OTOH, "identity" isn't quite right either. Though it is the term
used in RFC 2821, that RFC in no sense requires that the "identity"
identify a single server.
John K. has been very clear on that point. Section 2.3.5 says
The domain name given in the EHLO command MUST be either a primary
host name (a domain name that resolves to an address RR) or, if
the host has no name, an address literal, as described in
Section 4.1.3 and discussed further in the EHLO discussion of
Section 4.1.4.
It is true that section 4.1.4 specifies that giving the affiliation
instead of the host name cannot be punished by rejecting messages.
However, that wording obviously implies that no reliable affiliation
information can be derived from the EHLO name. John himself
suggested to use VHLO if affiliation is required. In his words
Although I'd predict that you'd have trouble
getting it off the ground, another possibility would be to
propose to replace EHLO with a validated-hello command, VHLO,
which would be just like EHLO except for support for a different
argument architecture.
[http://www.imc.org/ietf-smtp/mail-archive/msg05444.html]
Declaring the affiliation is VHLO's raison d'etre.
Hmm... I still think "affiliation" deserves to be multi-valued...
In what sense?
In the vhlo draft[1] I define two domains compatible if they share
at least one primary mail exchanger. Would that be a
multi-affiliation example?
[1] http://tools.ietf.org/html/draft-vesely-vhlo
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg