Seth Goodman wrote:
I think this is definitely not OK.
Then you're free to reject the mail coming from IPs marked as
"no MTA". But the S in SPF means "Sender", not "Recipient" or
"ISP". MTAMARK is no "Sender Policy", it's a "ISP Policy" (or
as you said AUP). And you as recipient are free to have yet
another policy like "IPs with an odd digit some are bad", or
"I only receive mail on Sundays, otherwise 554".
None of my ISPs can define the sender policy of the domain
xyzzy.dnsalias.org, the only parties allowed to do this are me,
because it's my host, and DynDNS, because it's their service.
And my "sender policy" for xyzzy.dnsalias.org is rather simple:
I never send a line with the word DATA ;-) Please note that I
do send HELO / MAIL FROM / RCPT TO from time to time, just for
fun related to rfc-igorant.org. Of course you are free to say
554 before I have the chance to finish my ignorance test. It's
something between you (recipient) and me (sender), and you can
ask the owner of my IP (ISP) for your decision. You can also
lookup the SPF record for xyzzy.dnsalias.org - there is none,
draw your conclusions. There's also no MX, and there's no
smtpd, but you'd find an identd. It's up to you.
But don't tell me that I can't have "v=spf1 +a -all" if I want
this, that's none of your business (more precisely: It's the
business of DynDNS, and I know their price list).
it's the ISP's AUP expressed in their SPF record.
There is no SPF record for xyzzy.dsalias.org. And IPs used by
me belong to different ISPs depending on my mood and the costs.
I use at least 3 different ISPs, and as soon as I've got a IP
one of my scripts updates xyzzy.dnsalias.org.
The ISP owns the netblock
Ok., but they don't own xyzzy.dnsalias.org, so what ? If they
want to say that none of their dynamic IPs is an MTA, then they
are free to do so. I'm free to state something else. You're
free to do whatever you want. As I said, actually I don't send
mail because I don't send DATA, but that's my decision. There
is no AUP at my ISPs saying that I must never send DATA. They
have working abuse desks, unlike Spamcast.
the user agrees to an AUP for a given grade of service
I'm definitely not allowed to spam. But I'm allowed to send
mail (of course that's a stupid idea with a DynDNS domain and
no MX, therefore I won't do it. But in theory I could arrange
for a reliable mail setup with dynamic sender IPs).
We have no business helping anyone circumvent a netblock
owners' stated policy on the permitted use of their IP space
_You_ have no business with my domain, my ISP, and my sender
policy. Your business is your "reject policy". Let's take a
simple policy like "v=spf1 -exists:%{ir}.bl.spamcop.net +all".
From my POV that's fine, it says "whatever I do, I never send
mail from an IP listed by SpamCop". Actually some spammers do
this, therefore it's not good enough for you as recipient.
Their netblock, their rules
If there are rules. And if many recipients (not only you) use
these rules, then the spamers use IPs without rules. And my
rules as sender (for a domain) are not necessarily identical.
And your rules as recipient are completely different. Maybe
you have one of these self-learning filters, and it deletes all
mails with a SPF header including PASS, shit happens.
This is analogous to cable box descramblers that circumvent
cable TV charges.
If there are rules, and if they update RfC 282?, then it's time
to discuss this. At the moment you IMHO confuse SPF and FUSSP,
the "S" stands for "sender", not "spam".
Spammers can and will use this construct, should we provide
it.
As far as I'm concerned I don't really believe in this "united"
stuff, it tries to integrate too many different ideas. I like
the classic syntax and semantics, and I'm quite surprised why
MARID doesn't try to _simplify_ classic SPF. Get rid of the
SOFTFAIL, get rid of the exp=, build on the include_subdomains=
idea, and be done with it. But for some obscure reasons MARID
needed weeks to dump the weird XML interface on the DNS level,
and now they don't have enough time to improve the real thing.
Dynamic DNS service is cheap enough that it is in the
disposable category.
Not at DynDNS, but of course the spammers could ask their good
friends at say DirectI to arrange "something". And then pay
with credit cards found in some phishing... :-( So yes, this
could be the case, and it's your decision what you do. Maybe
say "if it's DynDNS or godaddy I accept it, but if it's DirectI
or even remotely related to TLD .biz I reject it".
All this for the sake of vanity domain hobbyists who are
unwilling to pay for the services they wish to use.
That's arrogant. SPF was never meant to be the final ultimate
solution of the spam problem. It's about billions of useless
bounces. And forged MAIL FROM addresses. It's a *=_S_=*ender
Policy. PASS means it's most probably not forged. It doesn't
mean no spam.
We don't have to bend over backwards to support this group,
which incidentally includes lots of script kiddies.
_s_ _e_ _n_ _d_ _e_ _r_ policy framework. The owner of the
domain in a MAIL FROM (etc.), not the owner of the IP. Don't
confuse this.
I'm sorry if this is inconvenient for hobbyists, but there
are more important concerns on the table.
As long as "hobbyists" are allowed to send mail they have also
the right to state their policy. And what you call "hobbyist"
includes small businesses. Real hobbyists know much more about
these problems than big companies like Spamcast.
If you are sending mail from a vanity domain, we don't
necessarily know your ISP, as headers are easily forged.
| whois -h whois.abuse.net xyzzy.dnsalias.org
| abuse(_at_)dyndns(_dot_)org (for dnsalias.org)
Where's the problem ? You have all facts, whatever IP I use,
GetHostByAddr() won't return xyzzy.dnsalias.org, and it's up to
you to interpret these facts.
As far as abuse(_at_)yourMX, that's like sending a complaint to
abuse(_at_)enlarge-it(_dot_)com(_dot_) I don't call that accountability.
Then you're free to block all domains with this MX. You're
also free to block domains without MX. Your decision as the
recipient.
Sending IP's need to be static because that's the only way
they can be blacklisted.
Implement MTAMARK. Get MARID to support it. Convince ISPs to
use it. And note that spammers can circumvent your efforts for
the next decades until it's implemented everywhere. SPF is
about Sender Policies, it's not about dynamic IPs.
Dynamic IP's _cannot_ be blacklisted
Of course they can. Whenever GetHostByAddr() returns a string
ending in *.dip.t-dialin.net, then it's a dynamic IP. Several
millions of IPs listed, now add to this "list" as you see fit.
that's why they're not accountable.
abuse(_at_)t-online(_dot_)de knows how to handle spam from these IPs, but
that's none of your problems because you simply reject _all_
mails from these IPs. Your rules as recipient, their rules as
ISP. Other recipients are free to use other rules. Other ISPs
can have other rules. And SPF is "only" for the senders.
A domain owner can't dictate the use of someone else's
netblock and SPF shouldn't support that functionality.
Everybody is free to use "v=spf1 +all". If you are the owner
of x.y.z.0/24 you cannot force them to add "-ip4:x.y.z..0/24".
If you agreed to an AUP that stipulates that you cannot run
an MTA on your connection, then you can't.
I didn't. In fact that's impossible for an ISP, because if a
provider offers "internet minus port 25", then it's a I-25SP.
As long as ISPs exist I'd always go to ISPs. I-25 is lame, it
is for Win box administrators clicking on every link.
The same goes for a web server or DNS server,
BTW, I don't send DATA and have no smtpd, but as long as I'm
online there will be an inetd and a just-for-fun httpd. And
depending on my mood an ftpd and other services. No problem
with a modem, if something weird happens I can see the traffic
(Rx/Tx) and check what's going on.
I can see why you want to do this, but if the netblock owner
forbids it, you would be stealing their services.
My ISPs don't forbid it. And won't in the foreseeable future,
they have working abuse desks.
Maybe your objection is only the "trumps", and in that case
just read "could trump". It's only a slide, not a MUST in
some RfC.
I'm afraid that doesn't cut it. It needs to be "MUST NOT
TRUMP".
You want obviously something like a "Spam Policy Framework".
but that's not SPF as I understand it. And for your idea of
a "spam policy framework" the _sender_ is irrelevant, because
all spammers lie.
Bye, Frank