On Tue, 6 Jul 2004, Karl Prince wrote:
This "most" doesn't include users with a reliable MX (static
IP), and a say DynDNS domain with "v=spf1 +a +mx -all" policy.
I specifically said the problem was with dynamic IP's as you've
quoted me above. Of course this does not include static IP's.
When I ran dialup ISP in 1996 - 2000, the setup was such that from outside
you would not be able to tell which ip is dynamic and which is for static
dialup or isdn customer. Each modem port had its own ip and some ports
were reserved for certain customers, but most were used for general
dialup pool. All ports had standard reverse designation of "ppp-portxxx"
and unless it was for customer that requested its own ip block (rather
then one static ip) there was no change in reverse for dedicated customer
with one ip. Now if you think this is all old news, think again - not only
does this setup still exist in some places but more important is that dsl
providers have standard way to identify the ip blocks and this is usually
the same no matter if its dynamic ppp over eithernet over atm or if its
direct ethernet over atm with statically assigned single ip or ip block.
From outside it all looks the same except sometimes if network provider
actually follows arin rules (SBC, though they complain how they don't want
to all the time) you might see a swip for customer with 8-ip or 16-ip
block (but not for anything smaller). These ip blocks even if they are on
dsl re not only used by individuals but primarily by small businesses that
might want to run their own mail server on them (some managed to do it 5
years ago on single isdn line with single static ip even when I offered to
host their email domain for free!).
Now back to my case, If somebody from outside was deciding which of our ip
blocks were dynamic, all the ips in entire /24 used for the modem pool would
likely be put on some dialup RBL and if I were to complain about several
customer with static ips in the middle of all that, they would tell me
that change those ips to another block as whitelisting dozen individual
ips out of 255 is not convinient (and this would have been unlikely to
happen as customer might have already set his equipment to use that specific
ips, so why should I bother just to accomodate some rogue list with
listing that I did not authorize in the first place?). And not only that
but I'd bet I would have been told in not so nice a tone that afterward I
would have no interest in speaking with people who maintain dialup RBL
lists. Too many ISP operators are not on good standing or speaking terms
with RBL operators and their opinion is strongly that they should decide
on their own what ips should and should not be on certain rbl list. The
idea of marking through in-addr tree which ips should not be used for
accepting email is not new one and has been proposed on nanog list at
least twice but no consensus has been reached, but if it is left to ISP
to actually set which ip is dynamic or not or otherwise mark computers
from which there should not come any email, then I believe this will be
accepted and will be used.
IMHO any email from a dynamic IP is HIGHLY suspect, and I will
do whatever I can to reject it, SPF or not, it's my privledge
as the receiver after all.
You as an end-system MTA operator should be free to decide policies for
accepting and rejecting mail on your own terms, but don't be surprised
if overly restrictive filtering policies are not acceptable to your company
management. As otherwise how are you going to explain situation when you
your boss was traveling and using dynamic ip to send email and it was rejected
and this is just one small example. For businesses one incorrectly rejected
legitimate customer email is lot worth then ten incorrectly accepted spam
emails. I have multiple experience on this having consulted more then
one company.
Aside from the issues of zombies etc,
Which is why I think MTAMark style system will do more to combat spam then
classic spf mail-from. SPF is designed to stop forgery but requies record
and updates to millions of domains. SPF PTR records with "-all" being
deployed by only a hundred largest ISPs will have tremendous impact
having acounted for probably 90% of the ranges of zombies. Latest
estimates is that spam coming from zombies now accounts for 60 - 75% of
total volume. If we can stop this situation, this will be a big show for
us "the good guys" and will also give legitimacy for deployment of spf
records in general to stop other types of forgery.
no SPF record can be sufficently accurate on a oving target IP
address, many (caching) DNS implementations override
unreasonably short TTLs of DYNDNS type records, which will lead
to rejections of email from a domain by up to a day based on
their own (cached) SPF records.
If you're talking about somebody running a mail server on dynamic ip, I'm
against that setup and so would be the ISP providing them service. If you
see this happening often for same domain moving between ips in basicly
same dynamic ip pool, I'd recommend complaining to ISP so they had a nice
talk to their customer about possible service agreement violation. But
otherwise if these people have problems because of them using dyndns and
running mail server there, its the problem they brought on themselve.
They should instead pay ISP extra $10/mo for static ip or pay half that
for webhosting little extra for virtual of full dedicated server.
On the other hand as may have noted, some ISPs are just so damn "busy" and
that even if you pay for dsl service with static ips, getting them to
update PTR might take week or two. And there are of course those black
sheeps of local telcos with only 1% of properly trained personal who know
that people would use them anyway no matter how much they screw up because
they are monopoly and people in the area don't have any other choice...
So when I advocate MTAMARK or like records, I always have people immediatly
tell me that they are against it because they don't they dont trust their
ISP to properly set inaddr record and don't want their dsl isp blocking
their small personal mail server (here is a guy from Microsoft for example:
http://www.imc.org/ietf-mxcomp/mail-archive/msg01504.html). Then I came
up with this complex idea (now adapted as part of unifiedspf) that marid
records for EHLO and mail-from can override the inaddr record and the
other way around (the other way around is to allow quick way out for
forwarders who have not yet upgraded their software), this isfirst email
post that led to all this and explains the reasoning:
http://www.imc.org/ietf-mxcomp/mail-archive/msg00983.html
But there were still number of people who just didn't think inaddr is
good place for the records and somehow think its difficult to set it
up there. To address these concerns you saw the idea watered down to
putting records in already setup PTR names (if they got this far,
obviously inaddr is not a problem for that isp):
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200405/0238.html
Meng and myself has disagreed in the past on this list over the
MTAMARK=No being overridden by "valid" SPF records, I still
think there is no point in using MTAMARK, if it can be
overridden,
See above that there are many people who would not want to give its ISP
full control of what is and is not a mail server. Those geeks make up large
portion of the base that make current spf community on this very list or
on the MARID or IETF in general.
As for your concerns, while spammers who want to continue using zombies
may try to override PTR records, to do so will require them to have their
own domain and set its dns with specific SPF record that specific zombie ip.
Having to do something like that makes it possible to tell which spammer
"ownes" which zombies and will allow to significantly help law enforcement
in tracking spammers and proseuction.
I do want to point out that when overriding PTR SPF -all, the domain
should not be whitelisting entire net (+all or 0.0.0.0/0) or large size ip
blocks (like all comcast cable blocks), for this reason I think we should
have additional rules that overriding ptr requires whitelisting of that
specific ip on its own and not by means of ip block statement or by using
complex redirect statement. Or maybe this is something to think about for
the future if we really see serious abuse.
We certainly shouldn't provide a mechanism that trumps the ISP's AUP.
What AUP is a document providing rules for customer to follow (or rather
not to follow), most of the things AUP says customer should not do, they
can technically do just fine (or otherwise why bother with AUP?), its a
matter of the customer knowing what is wrong and not doing it and when
they do it, somebody complains and ISP disconnects the customer for
violation, that is how AUPs work everywhere and we're not changing it
in any way.
Dynamic IP blacklists are already incredibly useful. More and more
responsible ISP's are using them.
ISPs use them and at the same time hate them because of how many complaints
regarding legitimate emails not getting through they receive. The want
something better that will let ISPs identify each other's dialup pools.
Don't agree with me? Ask your ISP tech support personal!
Of course those ISPs that don't play it nice with their peers would continue
to be included in various RBLs including dialup ones if they dont want to
identiy and mark dynamic ips on their own!
P.S. People please remember that SPF is an ultimate final solution to spam!
Its just one step on the right direction in securying current email
infrastacture and making the system work to our benefit and not against us.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net