From: Frank Ellermann
Sent: Sunday, July 11, 2004 3:16 PM
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".
I partially agree with you on SPF and completely agree with you on
sender statements regarding legitimacy of email. SPF classic certainly
is not a spam prevention tool. It detects most sender forgeries, which
is necessary though not sufficient step to curb spam. Sender
authentication is also valuable in its own right, even if it only
validates the originating domain and not the complete sender identity.
Unified SPF, OTOH, does go beyond forgery detection. If SPF is
successful, spammers will simply move to disposable domains and publish
SPF records. This creates the need for further methods to discriminate
UBE from legitimate mail. I think it is a legitimate question whether
or not this belongs in SPF, but that is what is being proposed by Meng
in their RFC drafts. At this point, I can't say that I disagree with
it. It is definitely different from where we started, but I'm willing
to see where the debate leads.
<...>
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.
If that were truly the case, I wouldn't have brought up the objection.
Both Unified SPF and SPF classic give the recipient a single overall
result which is a logical composite of the separate SPF queries
involved. The user may not be aware of the conflict in the separate SPF
results, depending on exactly what goes into the SPF header, and even
that is available only after the start of DATA.
Fortunately, Meng showed me that the slide that I objected to did not
tell the whole story, but the text of the draft, which I failed to read
in detail, was explicit.
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200407/0196.html
What the draft language showed was that the domain owner's SPF pass
could only override the PTR domain's SPF fail in two cases:
a) there is a reputation result for the return-path domain higher than a
user-defined threshold, or
b) the IP (or domain?) appears on a user whitelist
This puts the default behavior, with no reputation service and no user
whitelist, as having a PTR domain SPF fail cause an overall SPF result
of fail, which I consider a reasonable default. My worry was that a
malicious domain owner (spammers publish SPF, too) could simply
designate the IP block of their zombie army as designated senders and
override the policy of the netblock owners.
"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.
Since I don't see that result separately, that's not currently possible
unless I write custom code. Again, if I am misconstruing the draft RFC,
someone please correct me.
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.
While it is certainly true that anyone can complain about the abuse to
the IP owners, I have done this for years and there are far better uses
for my time. Permissive acceptance policies puts the burden on
recipients and threatens the usefulness of email as a communications
medium. Since the majority of direct-to-MX mail from dynamic IP's is
spam or viruses, ignoring that fact puts us right back where we were a
few years ago before DNSBL's became more reliable: a giant daily spam
folder concealing an occasional false positive from a new correspondent
that is almost impossible to detect. Permissive acceptance policies
force the recipient to rely on content filters, which I believe should
only be the last line of defense, and we should strive to reject the
great majority of UBE before DATA. If the daily spam folder only
contains a half-dozen messages, spotting the occasional false positive
is no longer such a problem. Rejecting a legitimate email before DATA
causes a DSN and has no serous consequences, as far as I'm concerned.
Silently dropping a false positive from a content filter, OTOH, is an
unacceptable outcome.
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.
That's precisely the problem. Spammer lie, but ISP's tend not to, at
least when it comes to acceptable use of an IP.
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.
That is correct, it is not a forgery. But if it comes from a class of
lines where the great preponderance of direct-to-MX messages are UBE or
viruses, I don't want it.
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.
In my mind, it is about giving recipients more tools to decide what
messages to accept. Some of it is definitely _not_ about forgery
prevention. The whole concept of reputation systems allows the user to
reject messages that are not forgeries but are most likely UBE. The
overall construct recognizes that if SPF is a success, spammers will
simply move to disposable domains and publish SPF records. RHSBL's are
another after-the-fact solution. We should prefer the ability to reject
before massive abuse occurs.
[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).
I sympathisize with your situation. The same is true where I live, as I
have only one choice of local provider. My dynamic IP DSL costs about
USD$60/month for 1.5Mbit service, while a static IP DSL would cost about
USD$300/month for a 384Kbit line. That was one of my easier choices:
use the dynamic IP DSL for connectivity only and host the domain at a
large, reliable provider. With only about 15 mail users, I really can't
justify running my own MTA, even if a static IP were reasonably priced.
If we were a medium or large organization, the economics would look
different.
Actually, having your MX be unreachable for a few minutes a day is not a
problem. The key on your end is to rapidly detect the loss of your IP
(or connection) and re-establish it immediately. DHCP servers are
supposed to give the same IP back to a given requesting MAC address as
long as it is still available, so the great majority of the time, your
IP will not be outdated in local DNS caches (unless your provider
specifically violates the RFC's just to make your life harder).
Alternatively, you could use the backup MX services of your dynamic DNS
provider.
--
Seth Goodman