Re: op=dk

Frank Ellermann wrote:
> Stuart D. Gathman wrote:
> > I liked the proposals to advertise other authentications in
> > the SPF record via modifiers.  E.g. dk=... ses=...
>
> I've thought about op=dk "I use DK".  But what's it supposed
> to mean ?  Some possibilities:
Actually it would mean "My DK information is at ...", or "My PSG 
information is at ...".
So SPF doesn't need to know what the contents of the string means. All 
an SPF client would have to do is to return an array of "other" 
mechanisms when it returns from its evaluation.
The call to the spf_check function would return the SPF result as per 
SPF rules, and also any "other" information it may find:
array spf_also_found;
spf_also_found["dk"]=_blah
spf_also_found["psc"]=_boo
spf_also_found["pra"]=_ahh

Then the MTA vendor would be able to integrate all the features they 
want, and be able to use this array to save a DNS query. MTA vendors who 
strive for high performance would appreciate the saved query, I think.
Having the SPF checker output this info would not oblige the vendor to 
do anything or take any action. They can chose to ignore it.
Of course that in some cases the MTA will ignore the "sfp_also_found" 
array for mechanisms that don't make sense, security model wise.
For instance, if an SPF record specifies 
spf_also_found["reputation"]=blah.com, the receiving MTA should probably 
ignore it, as it's the recipient's choice of which reputation services 
to check, not the sender's.
If this optimization proves to be a good idea, I would prefer that all 
o* modifier namespace be set aside for these side-band communications, 
in order to avoid future conflicts with new mechanisms that happen to be 
 called "exp" or "m", or even with other implemetation-specific 
extensions. That way if I add later a psc= modifier for some specific 
purpose, I won't have to worry about confusing my psc= modifier 
(panasonic-signetics-credentials)) with the psc= (public spam control) 
modifier that is necessary for some new standard.
> - If SPF says FAIL but DK says "GOOD" ignore the FAIL, it's
>   only a minor case of 1023/2821-alias forwarding confusion.
>
> - If SPF says NEUTRAL but DK says "BAD" or "GOOD" ignore SPF.
>
> - If SPF says PASS but DK says "BAD" - what happened ?
>
> And what's going on if my sender policy covers all my mail
> providers, but only some of them support DK ?  (Hint, I know
> shit about DK, if that's impossible please tell me).
That is for the MTA developers to figure out how to integrate all the 
methods they wish to support.
We're only giving them a little help in avoiding needless performance hits.

> > Even if the maintainers of the other protocols don't like it,
> > it doesn't hurt to put them in the SPF record.
>
> Sender policies shouldn't advertize arbitrary garbage, it should
> be _very_ useful for the MX of the receiver.
Is performance not an important requirement for MTAs ? I've read white 
papers that analyze MTA performance down to how many disk accesses they 
do, based on their queueing model, how many DNS lookups they do, and so 
n. They were comparing even the organizations of the disk qeues. 
sendmail uses 2 files per queue item, where some other uses only one.
From a system perspective, all these details matter, as they make 
sometimes huge performance differences. 20% is a big difference, as it 
translates directly into 20% more dollar cost to implement (I'm talking 
about the mail agregators and other high volume mail services, and not 
spammers, which we've grown to associate with high-volumes of mail). For 
a budget of 1 million, an IT manager would really have to make a good 
case for the extra $200k
A systems engineer would take two mail servers with different software 
installed, tune them for best performance as per the vendor's 
recommendations, and then test their perfomance by sending a large 
number of test messages. Then he/she would make measurements of the 
output, and calculate things like throuput, mean-time-to-deliver, min 
and max times to deliver, maybe even break down the statistics and chart 
them on graphs that show the relationship between message size and 
throuput. Then they might add SPF to the competing MTAs, and measure 
what the incremental performance cost of each might be. Then, add DK, 
and so on.
Besides, it appears to be general attitude that whatever the big service 
providers adopt must be good enough for the masses, so adoption by large 
services sometimes drives general adoption rates of any technology.
> > For those recipients that check SPF first, you have a nice one
> > stop list (when provided by the sender).
>
> Okay, op=csv is out, it would be stupid to check SPF before CSV.
> But what's the precise meaning of op=dk ?  Op=ses is out, there
> was never a published I-D for SES, op=rumpelstiltskin is useless.
Right.. some of the extensions don't make sense, and the record 
publisher should know not to waste TXT record bytes by including them.
Regards,
Radu.