Seth Goodman wrote:
this was not a personal attack, I was criticizing an idea
that Meng proposed in his slides.
Yes, sorry, I didn't feel attacked, I was only very worried
that you confuse the roles of domain owners / IP owners /
recipients, and that you want SPF as an anti-spam scheme.
Which it isn't, and the _sender_ of spam is the last source
where I'd look for their definition of "legitimate mail".
It's a dynamic process, at the moment we have a handful of
domains (relatively) publishing classic SPF records, and a
handful of recipients (relatively) checking these records.
It will be years until SPF / MTAMARK are widely adopted.
Weng's proposal tried to solve one temporary problem in
this transition. And your objection was based on the then
possible abuse. I've no problem if you don't accept any
mail from dynamic IPs, quite the contrary, I support this.
But some senders may want this, and some recipients may
accept this, because it's not necessarily abuse. It
could be a simple case of "direct is better than a relay"
(privacy etc.), and technically it's allowed. If there's
a conflict of interests between domain owner / IP owner /
recipient, then SPF syntax is not the place to solve it.
But at least it can document the different policies of
domain owners and (after adding "unified PTR") IP owners.
Good enough.
Unified SPF shouldn't build in a mechanism that makes the
domain owner's policy dominant. That's all I'm arguing.
That's not really the case, because the recipient is free
to interpret a conflict of published policies in any way.
The proposal only gives one possible explanation of this
conflict, you can ignore it, if you don't like it.
"let the recipient decide". While that is clearly in the
spirit of letting anyone do anything, it is not in the
interest of forgery prevention, which is what, IMHO, SPF has
always been about.
If I'd use a policy "v=spf1 a -all" for mail sent directly
from my box (with the corresponding DynDNS domain), then no
other IP is allowed to send MAIL FROM this domain. That's
the purpose of this policy, it works.
I wouldn't change this policy depending on statements of my
actual ISP, even if one of these ISPs marks the relevant IP
as "no MTA". That's their business. Now either you reject
my mail sent from a IP marked as "no MTA" (=> ready, I have
to find another way to send my mail to you), or you accept
it.
If you accepted it, and it is spam, you would probably send
a complaint to the owner of these IPs. Maybe the owner
then says "don't accept mail from IPs marked as no MTA".
Then you'll probably change your procedures for all IPs in
the same category, either by ISP or by MTAMARK. In both
cases see above => ready, no more spam from this class of
IPs.
Or the ISP says "tnx for info, this customer violated our
AUP, and we'll terminate his account if he does it again".
You can believe this, or you don't, more or less the same
situation as above or without SPF. If you believe it you
can continue with your procedure "let MAIL FROM SPF trump
PTR SPF", because you want mail sent directly to your MX.
And if you don't want this the whole discussion is useless,
because you always say 554 as soon as you see the IP. The
proposal is only relevant if you want to accept some mails
sent directly to you (resp. your MX).
It's always about _your_ decision, it's nothing the owner
of the domain can or should do. The domain owner states his
policy, and we know that spammers lie. With or without SPF.
give recipients a better shot at rejecting forgeries
If I'd send mail directly to you using a domain with a
corresponding sender policy, then that's not a forgery.
The SPF-for-PTR / unified MTAMARK / or whatever the name
is today has nothing to do with forgeries, it's an anti-spam
or AUP issue. In the worst case it's a "replace all abuse
desks by Dave Null" scheme. That's the problem of "unified
SPF", it's not more clear what it's about.
[general DyDNS cosiderations]
I'm not saying that no one can do this. That is a matter of
personal choice.
It's not only a matter of personal choice. Where I live static
IPs are _really_ expensive, and dynamic IPs (with flarates) are
relatively cheap. The marketing says "always on", and only in
the fine print you find something about a forced disconnect
after 24 hours "for technical reasons", but of course you can
reconnect immediately.
Not good enough for a reliable mail solution (unless you don't
care about a daily time window where mail could arrive at a 3rd
party), but if your MX is reliable, it _could_ be good enough
to send some "crash mails" (the FidoNet term for direct to MX).
Bye, Frank