On Tue, 2004-09-21 at 01:00, Matt Sergeant wrote:
On Mon, 20 Sep 2004, Douglas Otis wrote:
This is a repeat of an older debate. This would not be an improvement
over the current CSV draft. SPF often requires a series of lookups to
resolve an address list. This list is often not fully defined as it is
commonly intended to associate mailbox domains with a much larger set of
MTA addresses. It also may allow the EHLO domain to use SPF/Sender-ID
records as a means to spoof, as these records are often open-ended. The
host name used within the EHLO domain will require a separate record
anyway, so why not use a record that achieves an answer within a single
lookup?
My argument for this idea is simply that we settled on the SPF format
simply because single lookups (an "exists" lookup) were not flexible
enough for people's full needs. I doubt CSV's single lookup will be
either. Of course there is nowhere near as much adoption of CSV as there
is of SPF so we can't possibly be certain of this yet.
You are right. Much like a post-mark, the CSV records simply fix SMTP
EHLO authentication to lay a solid foundation upon which other
relationships can be asserted using additional records. Importantly, an
authenticated MTA name is strong enough to provide reputation
assertions. Building upon a validated list of MTA names allows a
relationship with some mailbox-domain and some vast mail channel to be
asserted using a simple name list. There would be little motivation to
spoof the mailbox-domain/mail-channel (open) relationships, as this
identity would typically be unable to serve a gate-keeping function. In
the few cases where it is used in this manner, the outbound mail-channel
must not be shared, and recipients must be alerted to not offer a
forwarded mail address.
By allowing the MTA to be validated, this identifies where the mail
originated, much like a post-mark. Should you receive a letter from
Uncle Jon, but from a different city, you can write back and asked about
his trip. If he says "What trip?" then the post-mark served a valuable
service. If there was a crime, this electronic post-mark indicates
where to obtain logs to discover the true source of the message. The
post-mark itself may be all that is needed should this be used by a
single organization.
At some point in the future, it is possible mail providers may request
customers to create CSV-CSA records to enable the use of customer's
domain within the EHLO name for messages being sent on their behalf.
This assumes the CSV name reputation trumps any IP address black-list,
as it should.
This additional record could be:
_marid.my-mailbox-domain.tld. PTR my-isp.com.
_marid.my-mailbox-domain.tld. PTR my-support.com.
_marid.my-mailbox-domain.tld. PTR my-remote-office.com.
...
The scope of the assertions implied by this _marid record should be for
a single field, the RFC2822 From and nothing else in my view. As I said
in another post, it could be for the REF2821 MAIL FROM or the PRA
selected field for that matter.
The point is simple. By using a name list rather than an address list,
there is no need for highly risky and time consuming subsequent lookups
to just discover addresses. A name is a much more concise means of
expressing this relationship which does not involve the same level of
maintenance and trouble.
The great thing about rehabilitating the EHLO name, is that this name is
provided early in every SMTP session. The EHLO name is captured within
the message headers to allow tracing. There is no need for submitter or
to invent new mail headers to discern where the message is originating
with the use of CSV applying the post-mark so to speak.
On Mon, 2004-09-20 at 18:50, Matthew Elvey wrote:
On 9/20/2004 5:21 PM, Douglas Otis sent forth electrons to convey:
On Mon, 2004-09-20 at 16:33, Matthew Elvey wrote:
Here's the idea in a nutshell: CSV makes use of extant SPF records
which already list tens of thousands of domains that are authorized
for use in HELO.
Who supports/opposes this change?
Ney.
This is a repeat of an older debate.
No, I'm making a different suggestion. Please read the whole post!
I'm eliminating some or all of the records that you mention having a
problem with below.
I should have stated one thing clearly: only +type components of
records would be relevant; ~type and ?type would be ignored.
As I said, this will allow the use of other record types to spoof the
EHLO name. The SPF type of record will normally be across an entire
array of providers and not for a single host. One compromised system
within this vast region can then utilize one of these records to spoof
the EHLO name then. If reputations are based upon the MTA name and not
the mailbox domain, then protecting the MTA name would be much more
important. It MUST not be possible to mix these records out of this
concern.
I registered your Nay on Jabber...
Thanks.
SPF often requires a series of lookups to resolve an address list.
This list is often not fully defined as it is commonly intended to
associate mailbox domains with a much larger set of MTA addresses.
It also may allow the EHLO domain to use SPF/Sender-ID records as a
means to spoof, as these records are often open-ended.
No open-ended records would be allowed. I don't think the fact that,
e.g. +0/0 is allowed is of much concern, as spammers have demonstrated
they can create MARID records for their own domains quite well; A&R are
required.
The host name used within the EHLO domain will require a separate
record anyway, so why not use a record that achieves an answer
within a single lookup?
We should, as my post makes clear. But there are reported to be what,
~300,000 SPF records? Why not use them to the extent that I suggest?
These records are for a different purpose, and expose a different set of
machines. The EHLO record set must be kept narrow in order to serve the
purpose of establishing accountability. The broad and weak nature of
the identities obtained using SPF/Sender-ID are not useful for this
purpose. SPF/Sender-ID should be viewed as informative for but a few
exceptions.
-Doug