----- Original Message -----
From: "wayne" <wayne(_at_)midwestcs(_dot_)com>
To: "IETF MARID WG" <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Monday, June 21, 2004 11:33 PM
Subject: Re: FW: Drive Towards Consensus
Message Types Tied to Individual Mechanisms
------- ----- ---- -- ---------- ----------
Many domains send both non-bulk and bulk mail, generally through very
different parts of their organization. It may be useful to have
annotations on an SPF mechanism that describe the kinds of mail they
send. For example:
v=spf1 +mx/bulk +indirect:comcast.com/nonbulk -all
Again, I see this as a case of being "not useful because no one will
believe unverifiable claims."
Jim, I agree with Wayne. I would not support MARID domain defined
reputation lookup. In my opinion, reputation lookups should be a
server-side sysop defined factor because sysops will trust thier setup. Not
the remote domain. In our current design implementation, sysop defined
reputation lookups is done first before any LMAP method lookup.
I would suggest that Accreditation Service Bureaus (ASB) trying to "buy"
into the MARID concept by augmenting into the validation scheme, are
probably only going to work (feasible) as a "permit" concept. For
illustration purposes only, the domain policy can look like this:
(whatever format) MARID=v1.0 ... .... +accred:XYZ-###### -all
where XYZ-#### is some combo of site code+permit code assigned by the
Accreditation Service Bureau to the domain. If the service is also part of
or supports this service, then the ##### number would be part of the lookup
table pointing to the site. example, ABC-1002-232. If the server is
supporting this permit, then ABC would be associated within the server-side
lookup table to get the site or lookup method and the entire permit + IP is
used to authorize the sender.
Ideally, the ASB can use a permit format for its members that also includes
other attributes or factors such as:
- Type of Member (Honest Direct Marketer? Company? ISP?)
- Expiration Date
but then again, this info could also be provided as part of the ASB query
response packet as it would offer a dynamic or more current ASB member
information.
The sysop will be the final judge as to whether it trust the ASB to validate
its mail sending members. It (or something similar) is the only way I would
implement this concept into our package. Not via a sender defined MARID
record with no linkage to the server-side/sysop approved usage.
This is true. The current SPF spec says that modifiers are position
independent and therefore you can't use them to mark up individual
mechanisms.
I think we could change the SPF spec to allow modifiers to be
(optionally) position dependant and not cause problems for the
installed base of SPF records. That is, we could say that things like
"redirect=" and "exp=" are position independent, but allow for new
modifiers, such as "targetrep=" and "mailvolume=" to be position
dependant. So, it would be possible to say "v=spf1 mx mailvolume=bulk..."
and have the mx: mechanism marked up.
I have checked the SPF records that are listed in the Adoption Roll
and my survey of the 1.3 million email domain names. I could find
none that wouldn't work just fine with this change in the SPF spec.
I'm not sure I really think it is a good idea to make this change, but
I think it is a valid option.
Wayne, adding unknown extensions before the final ALL directive will break
(create a SPF_UNKNOWN directive error) our current installed based of
Wildcat! SMTP servers with SPF support. Can't force people to upgrade and
it wouldn't be fair in general to all current SPF installations that may not
agree with an ever evolving "version of the month" SPF format.
Wayne, it is too bad in the "product world", 2nd comers always have the
advantage of learning and improving upon the originators of ideas. That
is just par for the course. Microsoft has no installed base so they have
tons of redesign leverage to get it right. SPF does not. You have an
installed base that can not be ignored. The worse thing to do here is to
continue to kludge SPF with an ongoing effort to match the XML format. So
my recommendation for the MARID version of SPF is either a closer format to
XML or its basically time to go to V=SPF2 where you can afford new well
defined extended SPF format ideas.
This will allow us to maintain compatibility for V=SPF1 systems and also
support the new V=SPF2 MARID systems. SPF2 will naturally be backward
compatible with the extra considerations for extensions, including the rule
order/position issues.
Anyway, please kind in mind that this on-going MARID extension "challenge"
between SPF vs. XML may be all for nothing (or less value). There is no
guarantee implementers will support the extensions. Maybe a few simple
ones, but not all. Extensions need to make sense and it can't be something
that will increase the cost of implementation or adoption.
Lets use Reporting for example.
Do you honestly believe that sysops will add overhead to the outgoing queues
to send reports?
If anything, I see this as a possible "commodity" where maybe the IBM's and
the Microsoft's will pay a small fee (penny per report) to ISPs. But I
sincerely doubt servers will start to send reports all over the place
especially when it becomes a popular extension and sender request. If we
were to implement it (and probably will) it will only be offered as part of
current Report Generator where the sysop defines the report filters, report
formats, etc to create scheduled reports for admins and management.
We could offer a dynamic reporting system too if that is what the sysop
wants. But in general, do you see what's going here?
The extensions, especially something like reporting/notification, increases
the design complexity and cost for MARID implementation. All this "extra
gravy and candy" extension considerations should be secondary to the key
goal of MARID - authentication. It should be explored, no doubt, but from
the standpoint that its part growth plans for future versions of MARID. But
it should not hinder MARID initial adoption.
Don't get me wrong. We love to write feature rich software. But if we use
this reporting extension idea, we are talking about 1 versus 3 possibly 4
project development efforts:
Core MARID implementation: Total projects = 1
o WCSMTP
- New Core MARID options
Core MARID Plus Report Extension: Total Projects = 3/4
o WCSMTP with more design issues
- New Core MARID options
- New Report Control Options
- New Report storage design
o WCREPORT (Report Generator)
- more/new report filtering rules
- more/new report output rules
o WCEVENT
- new MARID Report objects for scheduling
o WCBILLING
- just in case the SYSOP want to bill IBM for the overhead.
Never mind the increase beta testing and longer field testing involved. For
what, a report extension? Neat idea, but later. Not now. Lets just make
sure that it will be possible to add the extension and others. I believe
that is essentially the key idea we want. For now, MARID authentication is
the key to get it into the market place first.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com