DNSBL BCP v.2.0

[Douglas Otis]

On Feb 9, 2007, at 2:14 PM, Frank Ellermann wrote:

> Douglas Otis wrote:
>
>> Why not mention the use of TXT records as a means of noting  
>> contact information?
>
> IIRC the name of that record is RP or similar, not TXT.

There are also TXT records that may accompany the A record.  Often  
this indicates a contact method.

>> Why must this be done via a web site?
>
> Because http is quite popular for transporting more than 400  
> bytes.  Nothing against gopher or whois, but...

Whatever gets used must be robust against DDoS attack without costing  
a fortune.  Other solutions might be more effective, so why rule them  
out.

>> I posted slides presented to the ISOI II at:
>> http://www.sonic.net/~dougotis/isoi/
>
> Comparing the size of the message with the size of the final  
> queries is bogus.

The attacker is sending spam anyway.  Even email traffic should not  
be considered part of the attack overhead.  This means the  
amplification is actually much much greater!

> The attacker has to sustain those queries from his own name server,  
> and with that it's a factor near 9 (11 or 12 queries to the  
> attacker, 100 queries to the victim).

The SPF macro language allows the same SPF script to utilize local-
part elements of an email address to cause any subsequent lookup to  
occur.  These scripts can enjoy a very long TTL and not be re-
queried.  The MX records and their targets then enjoy the difference  
between a negative cache TTL, where in many cases the number needed  
to seed an attack would not be many per local resolver.  The reality  
this problem is actually worse than the numbers listed and virtually  
free to the attacker, unlike most direct attacks, or even spoofed  
recursive attacks.

> The a * b * c * d stuff ignores caches, it's nonsense.

Queries are randomized by the local-part as needed.  Attacking  
queries will not be found within an cache.  This is not nonsense.

> As an attacker with 102,400 bots I wouldn't bother to figure out  
> who checks SPF and how their DNS caches work, and bet on ordinary  
> "call back verification".  Or let the bots flood the victim  
> directly with bogus queries.

SPF allows an attack to be reflected off of some ISPs resolvers at  
virtually no cost to their own resources.  These attacks are done at  
the behest of the attacker when recipients attempt to process their  
SPF scripts.  The attacker will still be able to send the same number  
of spams, while also completely melting down some targeted network.  
There will be very little evidence indicating how the attack is  
happening.  The domains being queried or their victims might not be  
found in any message.

> And it won't surprise me if some SPF implementations already have a  
> "NXDOMAIN processing limit" to catch your convoluted attempts based  
> on malicious MX records.

In in the libraries I reviewed, many don't even limit the number of  
targets being accessed.  What is a good limit for NXDOMAINs for SPF  
scripts?  How can it be determined whether these scripts have been  
upgraded?  Change the version of the script?  Wildcard MX or SPF  
records could be the next ploy, where the game continues unabated.  
This SPF attack is virtually free to the attacker thanks to SPF's  
macro features.  Why not simply authenticate the SMTP client and then  
associate various originating domains?  One transaction and  
absolutely _no_ risk to the Internet.

> Terminate policies with "+all" is also bullshit, the fastest way to  
> get a PASS for any IP is to use only "v=spf1 +all".  Of course  
> that's a really bad idea for somebody planning to stay on a white  
> list, but some spammers might like the cheap PASS.

bell.ca. "v=spf1 mx ip4:198.235.69.10 ip4:198.235.69.45  
ip4:198.235.69.46 ip4:206.47.0.168 ip4:206.47.0.173 ip4:206.47.0.177  
ip4:207.236.237.0/25 ip4:67.70.214.43 ip4:216.18.99.22  
ip4:69.156.197.234 ip4:66.241.131.163 +all"

The goal could be to list the IP addresses being used without SPF  
causing messages to be mysteriously lost, or to encourage use of very  
dangerous SPF script parsers.

Executing script from anonymous sources is a basic problem.  It is  
clear that MAAWG's Sender policy does not care about DDoS problem  
either.  It can't always be about avoiding complaints and making  
money.  Validate the SMTP client and this problem disappears.  A  
simple scheme for associating domains provides a safe means for  
registering paths or authorizations of DKIM signatures.  Providers  
must be willing to be held directly accountable for the messages they  
send by name.

-Doug

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Chris Lewis-2]

Douglas Otis wrote:

> Those offering a free service are not likely concerned about earning
> DNSBLs a bad reputation, especially they are bombarded by an ill
> considered scheme designed to keep the SMTP client nameless.

Those offering a free service do everyone else trying/using the same
thing a grave disservice by screwing up.

> There is a similar conversation on nanog about maps.vix.com.

> Here is a link to a possible solution.

Look closer, Doug.  It's the same solution.

It should be, because the guy who introduced it in that posting to
NANOG, is the same person who introduced it where we saw it ;-)

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Chris Lewis-2]

Chris Lewis wrote:

> Look closer, Doug.  It's the same solution.
>
> It should be, because the guy who introduced it in that posting to
> NANOG, is the same person who introduced it where we saw it ;-)

Whoops, not quite, it takes into account that you shouldn't put IPs in
NS records.  A worked example like the NANOG one using 127 addresses
would perhaps be best for the BCP.  Should touch base with Jon to see
why he used 192.0 instead of 127.

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Douglas Otis]

On Feb 8, 2007, at 8:44 PM, Matt Sergeant wrote:

> On 8-Feb-07, at 11:21 PM, Douglas Otis wrote:
>
>>> I don't get the idea of an arbitrary magic number "6 months".  
>>> For a list with say bogon IPs it would be "as long as necessary",  
>>> unlimited.  You address this later, but IMO no fixed limit also  
>>> here is clearer.
>>
>> Frank is right.  6 months does not make much sense.
>
> Please re-respond in light of my response to Frank here.

> "6 months is reasonable for a long listing, and this is very well  
> covered by the last point in this section - that a temporary  
> listing can easily be extended by (for example) receiving more spam  
> from this IP/range."

Listing intervals depend upon several factors.  One might be related  
to who manages the ASN.  Regularly enabling dormant IP addresses  
within a large, poorly managed network would be a very bad choice.  
What is the justification for 6 months?  A period that represents  
typical IP ownership is not likely 6 months.  Many of these systems  
are compromised and can be retasked to send spam once the IP address  
drops off a popular block list.  How is 6 months reasonable for a  
long listing?  Why not state a goal rather than setting some  
arbitrary period not based upon any information or rationale.

>> ---
>> 2.1.3. An Audit Trail SHOULD Be Maintained.
>>
>> A DNSBL SHOULD maintain an audit trail for all listings and SHOULD
>> make it publicly available in an easy to find location, preferably
>> on the DNSBL's web site.  Please note that making audit trail data
>> public does not entail revealing all information in the DNSBL
>> administrator's possession relating to the listing; e.g., a DNSBL
>> administrator MAY make the audit trail data selectively accessible
>> in such a way that spam trap addresses are not disclosed.
>> ---
>>
>> It is not possible to disclose _any_ email information without  
>> also disclosing where the message was obtained.  It is simply  
>> impossible to fully redact a message to provide such an assurance  
>> of non-disclosure.
>
> Hence why this is a SHOULD not a MUST. It's a tricky line - compare  
> for example the disclosure given by PSBL (almost full spamtrap hit  
> contents) vs SBL. Both presumably maintain an internal audit trail,  
> but one is public and one is private, but both are reasonably well  
> run DNSBLs.

Publicly listed messages likely represent a sacrificial source.  
There lies the rub.  What happens when a spammer has an above average  
IQ?  Your listed, but we can show you why?

-Doug

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Matt Sergeant-2]

On 9-Feb-07, at 8:12 PM, Douglas Otis wrote:

>> "6 months is reasonable for a long listing, and this is very well  
>> covered by the last point in this section - that a temporary  
>> listing can easily be extended by (for example) receiving more  
>> spam from this IP/range."
>
> Listing intervals depend upon several factors.  One might be  
> related to who manages the ASN.  Regularly enabling dormant IP  
> addresses within a large, poorly managed network would be a very  
> bad choice.  What is the justification for 6 months?

We decided to pick an upper limit. We picked the most respected DNSBL  
(Spamhaus' SBL) to give us that limit - 6 months (for ROKSO SBL  
listings). A spamhaus listing will drop off if the ROKSO spammer  
stops spamming for 6 clear months.

Remember we're not saying you have to wait the 6 months before re-
checking listing criteria. If the event (e.g. spamming) re-occurs  
before that six months is up (say at month 3) you reset the timeout  
period.

So a spammer suspends spamming from an IP for 6 months to wait out  
the timeout just to start spamming again, and you think that would be  
a bad thing? Frankly I think the internet community would be glad of  
the 6 month reprieve (and of course the subsequent relisting).

> A period that represents typical IP ownership is not likely 6  
> months.  Many of these systems are compromised and can be retasked  
> to send spam once the IP address drops off a popular block list.  
> How is 6 months reasonable for a long listing?  Why not state a  
> goal rather than setting some arbitrary period not based upon any  
> information or rationale.

The goal is stated. If it needs to be clarified we should do that.

>>> It is not possible to disclose _any_ email information without  
>>> also disclosing where the message was obtained.  It is simply  
>>> impossible to fully redact a message to provide such an assurance  
>>> of non-disclosure.
>>
>> Hence why this is a SHOULD not a MUST. It's a tricky line -  
>> compare for example the disclosure given by PSBL (almost full  
>> spamtrap hit contents) vs SBL. Both presumably maintain an  
>> internal audit trail, but one is public and one is private, but  
>> both are reasonably well run DNSBLs.
>
> Publicly listed messages likely represent a sacrificial source.  
> There lies the rub.  What happens when a spammer has an above  
> average IQ?  Your listed, but we can show you why?

Do you have an objection to this point being a SHOULD? Clearly DNSBLs  
maintain and even display audit trails and retain effectiveness. I'm  
lost by your argument here. The point of this section is that an  
audit trail is a valuable thing when there's a complaint about a  
listing, or some other issue, so even if it's not public the audit  
trail really should exist.

I sincerely hope you're not suggesting that the MAPS dnsbl's don't  
maintain audit trails, even if they're not publicly available.

Matt.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Douglas Otis]

On Feb 9, 2007, at 5:28 PM, Matt Sergeant wrote:

> On 9-Feb-07, at 8:12 PM, Douglas Otis wrote:
>
>>> "6 months is reasonable for a long listing, and this is very well  
>>> covered by the last point in this section - that a temporary  
>>> listing can easily be extended by (for example) receiving more  
>>> spam from this IP/range."
>>
>> Listing intervals depend upon several factors.  One might be  
>> related to who manages the ASN.  Regularly enabling dormant IP  
>> addresses within a large, poorly managed network would be a very  
>> bad choice.  What is the justification for 6 months?
>
> We decided to pick an upper limit. We picked the most respected  
> DNSBL (Spamhaus' SBL) to give us that limit - 6 months (for ROKSO  
> SBL listings). A spamhaus listing will drop off if the ROKSO  
> spammer stops spamming for 6 clear months.

Spamhaus is a very good organization.  The fact they use 6 months  
does not mean everyone should use 6 months.  For those using multiple  
lists, having different intervals increases protection when policies  
vary.  There are a vast number of IP addresses controlled by bad  
actors where playing a waiting game would be made easier when DSNBL  
operators standardize this rather fundamental criteria.  Not stating  
this interval has much more merit than stating it would ever have.  
What problem is being solved?

Those managing the list will likely adopt policies that minimize the  
administration of the list in most cases.  The draft already says  
that repeated occurrences can exponentially extend this interval.  
Would an occurrence within the same 6 months be counted as one?  Does  
the IP address need to be removed from the list before repeated  
offenses are counted?

> Remember we're not saying you have to wait the 6 months before re-
> checking listing criteria. If the event (e.g. spamming) re-occurs  
> before that six months is up (say at month 3) you reset the timeout  
> period.
>
> So a spammer suspends spamming from an IP for 6 months to wait out  
> the timeout just to start spamming again, and you think that would  
> be a bad thing? Frankly I think the internet community would be  
> glad of the 6 month reprieve (and of course the subsequent relisting).

When nothing has changed with respect to the IP address ownership,  
why not apply intervals according to the general management of the  
address space, rather than a pedantic treatment of each IP address  
individually?

>> A period that represents typical IP ownership is not likely 6  
>> months.  Many of these systems are compromised and can be retasked  
>> to send spam once the IP address drops off a popular block list.  
>> How is 6 months reasonable for a long listing?  Why not state a  
>> goal rather than setting some arbitrary period not based upon any  
>> information or rationale.
>
> The goal is stated. If it needs to be clarified we should do that.

DNSBL operators should mimic Spamhaus policies?  Don't suggest there  
is some magic period.

>>>> It is not possible to disclose _any_ email information without  
>>>> also disclosing where the message was obtained.  It is simply  
>>>> impossible to fully redact a message to provide such an  
>>>> assurance of non-disclosure.
>>>
>>> Hence why this is a SHOULD not a MUST. It's a tricky line -  
>>> compare for example the disclosure given by PSBL (almost full  
>>> spamtrap hit contents) vs SBL. Both presumably maintain an  
>>> internal audit trail, but one is public and one is private, but  
>>> both are reasonably well run DNSBLs.
>>
>> Publicly listed messages likely represent a sacrificial source.  
>> There lies the rub.  What happens when a spammer has an above  
>> average IQ?  Your listed, but we can show you why?
>
> Do you have an objection to this point being a SHOULD? Clearly  
> DNSBLs maintain and even display audit trails and retain  
> effectiveness. I'm lost by your argument here. The point of this  
> section is that an audit trail is a valuable thing when there's a  
> complaint about a listing, or some other issue, so even if it's not  
> public the audit trail really should exist.

An audit trail should exist.  There are considerations not covered in  
this draft about what can be made public.  Those considerations  
should be included.  This could brace users when they hear something  
that they don't want to hear.  "I can't show you the message."

> I sincerely hope you're not suggesting that the MAPS dnsbl's don't  
> maintain audit trails, even if they're not publicly available.

Don't worry, we are keeping storage companies in business. : )

-Doug


_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Frank Ellermann]

Douglas Otis wrote:
 
> There are also TXT records that may accompany the A record.
> Often this indicates a contact method.

If you're talking about TXT records accompanying DNSBL listings
they're generally URLs, the exp= in SPF is a similar idea.

> Whatever gets used must be robust against DDoS attack without
> costing a fortune.  Other solutions might be more effective,
> so why rule them out.

URLs are fine, they work for everybody, and you don't need I18N
considerations for http, it's a solved problem.  I'm a "whois"
fan, but there are cases where "http" has a few advantages.

>> Comparing the size of the message with the size of the final
>> queries is bogus.
 
> The attacker is sending spam anyway.  Even email traffic should
> not be considered part of the attack overhead.  This means the
> amplification is actually much much greater!

No, it means you've to compare queries answered by the attacker
with queries sent to the victim.  And that's a factor 9 with mx-
mechanisms in SPF, no matter what the attacker does.

> The SPF macro language allows the same SPF script to utilize
> local-part elements of an email address

There's no such thing as "SPF scripts".  You've enumerated the
macros in your PDF, they're all derived from the input IP, the
checked address, and the HELO identity.

The PTR stuff might appear to be a bit obscure, but actually it
is what any MTA checking reverse DNS does, once per session.
And completely unusable for any kind of attack.

> The MX records and their targets then enjoy the difference
> between a negative cache TTL

Whatever they enjoy or not, there's a limit of ten names per
MX record in SPF evaluations.  With different local parts the
attacker can cause queries to different bogus MX records on
his own server (per mail).  So he got rid of 1 of 11 queries
sent to his own server, if it's the same cached SPF policy.

He still has to answer the ten MX queries, each with 10 names
in the domain of the victim.  But in your PDF you say a*b*c*d,
one of that is used local parts, another is recipients per
mail.  With an assumption that all recipients check SPF at
their MUA, clearly against a recommendation in RFC 4408.

Ingnoring that - the number of local parts and recipients is
still irrelevant for the amplification of at most 10 queries
per MX.  The attacker can drop the complete SPF business and
try to abuse "call back verification".

> Queries are randomized by the local-part as needed.  Attacking
> queries will not be found within an cache.  This is not nonsense.

The "randomized" stuff are mx:%{l}.attacker.example mechanisms,
queries to the attacker.  One of your a*b*c*d factors was the
number of recipients of the same mail, the same local part.

> The attacker will still be able to send the same number of
> spams, while also completely melting down some targeted network.

While combining spam with DDoS attacks might be a fine art, I'd
pick a more direct approach and try to either spam or DDoS, not
some combo depending on an unknown number of recipients checking
SPF behind their border MX, against several SHOULDs in RFC 4408.

> In in the libraries I reviewed, many don't even limit the number
> of targets being accessed.  What is a good limit for NXDOMAINs
> for SPF scripts?

Evaluation => library.  SPF policies aren't affected by your
convoluted attack recipes, nobody uses ten mx-mechanism each with
ten names, and implementations were always encouraged (SHOULD) to
limit their efforts in addition to the MUST limits.  No working
policy needs to be "upgraded", talking about many non-existing
names in MX records was and is always a bad idea.

> Why not simply authenticate the SMTP client and then associate
> various originating domains?

The recommended SPF HELO check comes before the MAIL FROM checks.

If you don't like the latter you can still do the former, it has
the nice feature to work everywhere, not only at the border.  Of
course receivers could impose their own rules on HELO without
checking what the alleged sender proposes.  But receivers trying
to follow the RFC 2821 rules might like a kind of permission to
be stricter offered in a "v=spf1 a -all" or similar policy.

> bell.ca. "v=spf1 mx ip4:198.235.69.10 ip4:198.235.69.45
> ip4:198.235.69.46 ip4:206.47.0.168 ip4:206.47.0.173 ip4:206.47.0.177
> ip4:207.236.237.0/25 ip4:67.70.214.43 ip4:216.18.99.22
> ip4:69.156.197.234 ip4:66.241.131.163 +all"

A bogus policy, so what ?  Anybody can claim to be HELO bell.ca
or to send MAIL FROM:<whatever@...>

> The goal could be to list the IP addresses being used without
> SPF causing messages to be mysteriously lost

SPF doesn't lose mails mysteriously.  A FAIL detected at the
border is simply rejected.  The policy shown above will attract
spammers to abuse bell.ca whereever it pleases them.  If their
goal is to publish obscure lists of IPs they better dont't use
"v=spf1", they could say "our ips" without "+all" at the end.

> Executing script from anonymous sources is a basic problem.

Yes, fortunately SPF is no script, although you apparently argue
that MX records are a fundamental security problem.

Frank



_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Bill Cole-2]

At 8:01 PM -0500 2/9/07, Chris Lewis  imposed structure on a stream
of electrons, yielding:

>Chris Lewis wrote:
>
>>  Look closer, Doug.  It's the same solution.
>>
>>  It should be, because the guy who introduced it in that posting to
>>  NANOG, is the same person who introduced it where we saw it ;-)
>
>Whoops, not quite, it takes into account that you shouldn't put IPs in
>NS records.  A worked example like the NANOG one using 127 addresses
>would perhaps be best for the BCP.  Should touch base with Jon to see
>why he used 192.0 instead of 127.

I believe his idea is that it would always go out on the wire for any
machine instead of into the possibly less uniform world of loopback
handling.

I am not sure that makes a significant difference, except that in
some environments the packet on the wire to a 192.0.2/24 address will
elicit an explicit response rather than go off into nowhere, while on
many (most?) hosts a packet to a 127/8 address other than 127.0.0.1
will stay on the machine and get no response. On the good side, a lot
of packets aimed at 192.0.2/24 on a path through default gateways may
be noticeable to someone who can slap the mail admin to attention.


--
Bill Cole
bill@...


_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Douglas Otis]

On Sat, 2007-02-10 at 03:12 +0100, Frank Ellermann wrote:
> Douglas Otis wrote:

> >> Comparing the size of the message with the size of the final
> >> queries is bogus.
>  
> > The attacker is sending spam anyway.  Even email traffic should
> > not be considered part of the attack overhead.  This means the
> > amplification is actually much much greater!
>
> No, it means you've to compare queries answered by the attacker
> with queries sent to the victim.  And that's a factor 9 with mx-
> mechanisms in SPF, no matter what the attacker does.

SPF records staging an attack may have very long TTLs and utilize
local-part components of an email-address for generating subsequent DNS
transactions.  The macro expansion of SPF scripts allows the _same_
record to generate different attacking transactions.  SPF macro
expansion of local-part elements into subsequent DNS transactions is a
tremendous gift provided to an attacker.

This macro expansion feature eliminates further consumption of an
attacker's resources.  SPF allows attacks to be virtually free and
impossible to stop or defend against.  Nonexistent targets of MX records
is just _one_ means to stage an SPF facilitated attack.

Your calculations continue to overlook the likely difference between the
TTL of the MX record versus the negative cache TTL of bogus target A
records, and the advantages obtained from label compression.  Once the
negative caching period has elapsed, the attack sequence can then reuse
seeded MX records published with long TTLs.  Such an attack can continue
for hours, where the overhead needed to seed the sequence will be fairly
small in comparison, and can be neglected.

> > The SPF macro language allows the same SPF script to utilize
> > local-part elements of an email address
>
> There's no such thing as "SPF scripts".

SPF records will often appear completely meaningless without input
parameters and their related macro expansion.  SPF records include
commands that transform character strings, reorder label sequences, mix
different elements of the various input parameters, overlay DNS
transactions with CIDR masks, test existence of A records, include or
redirect the processing of a series of SPF record transactions,
etcetera, etcetera.

Describing SPF as anything less that a scripting language would be a
misrepresentation.  While this language is limited, it provides powerful
capabilities that can effectively stage DDoS attacks or greatly assist
in poisoning DNS caches.

> You've enumerated the macros in your PDF, they're all derived from the
> input IP, the checked address, and the HELO identity.

The checked "address" could be for the PRA.  The script might be run
once again for the MailFrom, and perhaps one more time for a DKIM
domain.  Limits established for SPF processes are for each "address"
being independently checked.  The PRA, MAILFROM and DKIM domains
represent a possibility for a long list of names checked per message.

> The PTR stuff might appear to be a bit obscure, but actually it
> is what any MTA checking reverse DNS does, once per session.
> And completely unusable for any kind of attack.

I agree.  Validating just the SMTP client is unlikely to result in
dangerous amplifications.  However, SPF scripts attempt to collect
addresses used by _all_ SMTP clients that might be utilized by an
originating domain.

A safe way to associate thousands of different SMTP clients with that of
some originating domain would be by "named reference".  This can be done
within one small and safe transaction. Alas, this is far from true with
SPF's demand for an entire IP address set.

> > The MX records and their targets then enjoy the difference
> > between a negative cache TTL
>
> Whatever they enjoy or not, there's a limit of ten names per
> MX record in SPF evaluations.

Many SPF script parsers fail to limit even the number of names resolved
in MX records.  Even so, there are ten MX records being processed with
perhaps 10 or more targets each.

> With different local parts the attacker can cause queries to different
> bogus MX records on his own server (per mail).  So he got rid of 1 of
> 11 queries sent to his own server, if it's the same cached SPF policy.

This would be true only the _first_ time the MX record is used.

> He still has to answer the ten MX queries, each with 10 names
> in the domain of the victim.

Label compression unfortunately works in favor of an attacker, in
addition to differences between negative caching TTLs and the TTL of the
MX records.  MX records can be reused without causing added overhead for
the attacker after negative caching of its bogus targets have expired.
This is what was meant by "seeding" the attack, and why the calculations
still underestimate the risk.

> But in your PDF you say a*b*c*d, one of that is used local parts,
> another is recipients per mail.  With an assumption that all
> recipients check SPF at their MUA, clearly against a recommendation in
> RFC 4408.

This number includes all MSAs (including MUAs). Where is the
recommendation against checking SPF at the MUA in RFC 4408?

Here is the _only_ text mentioning MUAs:

2.4.  Checking Authorization
...
   Typically, such checks are done by a receiving MTA, but can be
   performed elsewhere in the mail processing chain so long as the
   required information is available and reliable.

2.5.5.  SoftFail
...
   The domain owner wants to discourage the use of this host and thus
   desires limited feedback when a "SoftFail" result occurs.  For
   example, the recipient's Mail User Agent (MUA) could highlight the
   "SoftFail" status, or the receiving MTA could give the sender a
   message using a technique called "greylisting" whereby the MTA can
   issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the
   first time the message is received, but accept it the second time.

8.1.  Macro Definitions
...
   The "r" macro expands to the name of the receiving MTA.  This SHOULD
   be a fully qualified domain name, but if one does not exist (as when
   the checking is done by a MUA) or if policy restrictions dictate
   otherwise, the word "unknown" SHOULD be substituted.  The domain name
   may be different from the name found in the MX record that the client
   MTA used to locate the receiving MTA.

10.2.  SPF-Authorized E-Mail May Contain Other False Identities

   The "MAIL FROM" and "HELO" identity authorizations must not be
   construed to provide more assurance than they do.  It is entirely
   possible for a malicious sender to inject a message using his own
   domain in the identities used by SPF, to have that domain's SPF
   record authorize the sending host, and yet the message can easily
   list other identities in its header.  Unless the user or the MUA
   takes care to note that the authorized identity does not match the
   other more commonly-presented identities (such as the From:  header
   field), the user may be lulled into a false sense of security.

Section 10.2 even seems to require SPF checking be done at the MUA.
Prohibitions of MUA checking is not within the security consideration
section either.  It has not stopped MUA plugins like Spamassassin, or
those for Thunderbird, Outlook or Outlook express either.  

To quote Wietse Venema:
        "Junk mail is war. RFCs do not apply."

> Ignoring that - the number of local parts and recipients is
> still irrelevant for the amplification of at most 10 queries
> per MX.  The attacker can drop the complete SPF business and
> try to abuse "call back verification".

Don't ignore label compression (where nefarious tricks might also be
used), and of course, the differences between negative caching and the
TTL of reused MX RRs.  Greatly extending negative caching will create
other problems.

Whether there are random queries for bogus MX, SPF, or A records, the
attack is made virtually free with SPF.  Why would someone want to
expose themselves by attacking using other methods, when SPF allows the
attacker to completely hide, where even logs are not likely to assist in
tracing the source of the virtually free attack?

> > Queries are randomized by the local-part as needed.  Attacking
> > queries will not be found within an cache.  This is not nonsense.
>
> The "randomized" stuff are mx:%{l}.attacker.example mechanisms,
> queries to the attacker.  One of your a*b*c*d factors was the
> number of recipients of the same mail, the same local part.

In the MX record attack example, the "random" query would likely repeat
after a negative caching period.  Other attacks may never need to repeat
and would still not expend any of the attacker's resources beyond the
initial record queries.

> > The attacker will still be able to send the same number of
> > spams, while also completely melting down some targeted network.
>
> While combining spam with DDoS attacks might be a fine art, I'd
> pick a more direct approach and try to either spam or DDoS, not
> some combo depending on an unknown number of recipients checking
> SPF behind their border MX, against several SHOULDs in RFC 4408.

A direct attack would expose which systems are compromised.  Direct
attacks provide valuable information, especially for those wanting this
information.  The baseline of the example attack starts at 508 Kbit/msg
where the message would be sent anyway.  Use of SPF script parsers is
easily detected by bad actors, where recipients using SPF script parsers
are made well known.  The macro language of SPF even facilitates this
canvassing effort as well.

> > In in the libraries I reviewed, many don't even limit the number
> > of targets being accessed.  What is a good limit for NXDOMAINs
> > for SPF scripts?
>
> Evaluation => library.  SPF policies aren't affected by your
> convoluted attack recipes, nobody uses ten mx-mechanism each with
> ten names, and implementations were always encouraged (SHOULD) to
> limit their efforts in addition to the MUST limits.  No working
> policy needs to be "upgraded", talking about many non-existing
> names in MX records was and is always a bad idea.

Sigh. The attack is staged by a bad actor.  The bad actor creates the MX
records with perhaps 20 or more victim targets.  Many of the SPF script
parsers will attempt to resolve all targets for each of the 10 MX
records.  They might attempt to do this once for the PRA, and when that
fails, attempt to do this again for the MAILFROM.  There might even be
another attempt to process one or more DKIM domains.  Each MAILFROM and
DKIM script can happily end with '+all'.

> > Why not simply authenticate the SMTP client and then associate
> > various originating domains?
>
> The recommended SPF HELO check comes before the MAIL FROM checks.
>
> If you don't like the latter you can still do the former, it has
> the nice feature to work everywhere, not only at the border.  Of
> course receivers could impose their own rules on HELO without
> checking what the alleged sender proposes.  But receivers trying
> to follow the RFC 2821 rules might like a kind of permission to
> be stricter offered in a "v=spf1 a -all" or similar policy.

Alas, v=spf1 does not provide a scope definition nor would this prevent
bad actors from listing all scopes.  SPF represents an extreme danger
for the Internet as a whole.

> > bell.ca. "v=spf1 mx ip4:198.235.69.10 ip4:198.235.69.45
> > ip4:198.235.69.46 ip4:206.47.0.168 ip4:206.47.0.173 ip4:206.47.0.177
> > ip4:207.236.237.0/25 ip4:67.70.214.43 ip4:216.18.99.22
> > ip4:69.156.197.234 ip4:66.241.131.163 +all"
>
> A bogus policy, so what ?  Anybody can claim to be HELO bell.ca
> or to send MAIL FROM:<whatever@...>

This allows the listing of IP addresses to permit white-listing by those
providers who _insist_ on using SPF records for this purpose, such as
AOL.  This was the reason given for the comment made in the
presentation.

> > The goal could be to list the IP addresses being used without
> > SPF causing messages to be mysteriously lost
>
> SPF doesn't lose mails mysteriously.  A FAIL detected at the
> border is simply rejected.  The policy shown above will attract
> spammers to abuse bell.ca where ever it pleases them.  If their
> goal is to publish obscure lists of IPs they better dont't use
> "v=spf1", they could say "our ips" without "+all" at the end.


Some MTAs may check SPF before issuing DSNs.  Acceptance may have been
based upon the PRA, where the DSN checking might occur after a message
has been forwarded, and thereby rejected.  These messages may then
mysteriously vanish as a result.

SPF offers virtually no recipient protection, as it often checks unseen
headers.  SPF can not be safely applied at the MUA, however there are
those who will try such an unsafe practice.  SPF/Sender-ID is simply
unsafe from several perspectives.

Providers should adopt conventions for using APL records (RFC3123), and
avoid using TXT records altogether, especially SPF records.

> Executing script from anonymous sources is a basic problem.
>
> Yes, fortunately SPF is no script, although you apparently argue
> that MX records are a fundamental security problem.

No, the macro capability of the SPF script language is a _security_
threat!  Scripts often accept input parameters and remain in their
original form.  When run, scripts are then "interpreted" a "command" at
a time.  This definition becomes clearer after substituting "mechanism"
and "macro" used by SPF for the word "command".  SPF is truly a
scripting language.  Why say otherwise?

-Doug



_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Matt Sergeant-2]

On 9-Feb-07, at 9:03 PM, Douglas Otis wrote:

>>> A period that represents typical IP ownership is not likely 6  
>>> months.  Many of these systems are compromised and can be  
>>> retasked to send spam once the IP address drops off a popular  
>>> block list.  How is 6 months reasonable for a long listing?  Why  
>>> not state a goal rather than setting some arbitrary period not  
>>> based upon any information or rationale.
>>
>> The goal is stated. If it needs to be clarified we should do that.
>
> DNSBL operators should mimic Spamhaus policies?  Don't suggest  
> there is some magic period.

Our belief: There needs to be a sensible maximum time of listing  
should the entry no longer meet the listing criteria.

We think 6 months is a sensible maximum. This BCP is in NO WAY  
suggesting that an IP/range shouldn't ever be listed for longer than  
6 months, but that if your listing criteria is no longer met then the  
entry should time out after a maximum of 6 months.

Clearly we can state this better. I'll try and get Nick to use  
something from the above paragraph.

>>> Publicly listed messages likely represent a sacrificial source.  
>>> There lies the rub.  What happens when a spammer has an above  
>>> average IQ?  Your listed, but we can show you why?
>>
>> Do you have an objection to this point being a SHOULD? Clearly  
>> DNSBLs maintain and even display audit trails and retain  
>> effectiveness. I'm lost by your argument here. The point of this  
>> section is that an audit trail is a valuable thing when there's a  
>> complaint about a listing, or some other issue, so even if it's  
>> not public the audit trail really should exist.
>
> An audit trail should exist.  There are considerations not covered  
> in this draft about what can be made public.  Those considerations  
> should be included.  This could brace users when they hear  
> something that they don't want to hear.  "I can't show you the  
> message."

Good point. How about:

    A DNSBL SHOULD maintain an audit trail for all listings and it is
    RECOMMENDED that it is made publicly available in an easy to find
    location, preferably on the DNSBL's web site.  Please note that
    making audit trail data public does not entail revealing all
    information in the DNSBL administrator's possession relating to the
    listing; e.g., a DNSBL administrator MAY make the audit trail data
    selectively accessible in such a way as to not disclose information
    that might assist spammers, such as the contents of an email  
received
    by the DNSBL's spam trap.

Matt.



_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Chris Lewis-2]

Matt Sergeant wrote:

> On 9-Feb-07, at 9:03 PM, Douglas Otis wrote:
>
>>>> A period that represents typical IP ownership is not likely 6
>>>> months.  Many of these systems are compromised and can be retasked
>>>> to send spam once the IP address drops off a popular block list.
>>>> How is 6 months reasonable for a long listing?  Why not state a goal
>>>> rather than setting some arbitrary period not based upon any
>>>> information or rationale.
>>>
>>> The goal is stated. If it needs to be clarified we should do that.
>>
>> DNSBL operators should mimic Spamhaus policies?  Don't suggest there
>> is some magic period.
>
> Our belief: There needs to be a sensible maximum time of listing should
> the entry no longer meet the listing criteria.
>
> We think 6 months is a sensible maximum. This BCP is in NO WAY
> suggesting that an IP/range shouldn't ever be listed for longer than 6
> months, but that if your listing criteria is no longer met then the
> entry should time out after a maximum of 6 months.
>
> Clearly we can state this better. I'll try and get Nick to use something
> from the above paragraph.

Good idea.  I can see that that section is being misunderstood.

>
>>>> Publicly listed messages likely represent a sacrificial source.
>>>> There lies the rub.  What happens when a spammer has an above
>>>> average IQ?  Your listed, but we can show you why?
>>>
>>> Do you have an objection to this point being a SHOULD? Clearly DNSBLs
>>> maintain and even display audit trails and retain effectiveness. I'm
>>> lost by your argument here. The point of this section is that an
>>> audit trail is a valuable thing when there's a complaint about a
>>> listing, or some other issue, so even if it's not public the audit
>>> trail really should exist.
>>
>> An audit trail should exist.  There are considerations not covered in
>> this draft about what can be made public.  Those considerations should
>> be included.  This could brace users when they hear something that
>> they don't want to hear.  "I can't show you the message."
>
> Good point. How about:
>
>    A DNSBL SHOULD maintain an audit trail for all listings and it is
>    RECOMMENDED that it is made publicly available in an easy to find
>    location, preferably on the DNSBL's web site.  Please note that
>    making audit trail data public does not entail revealing all
>    information in the DNSBL administrator's possession relating to the
>    listing; e.g., a DNSBL administrator MAY make the audit trail data
>    selectively accessible in such a way as to not disclose information
>    that might assist spammers, such as the contents of an email received
>    by the DNSBL's spam trap.

I like.  Just change the last "the" to "a".

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Douglas Otis]

On Feb 12, 2007, at 9:16 AM, Matt Sergeant wrote:

> On 9-Feb-07, at 9:03 PM, Douglas Otis wrote:
>
>>>> A period that represents typical IP ownership is not likely 6  
>>>> months.  Many of these systems are compromised and can be  
>>>> retasked to send spam once the IP address drops off a popular  
>>>> block list.  How is 6 months reasonable for a long listing?  Why  
>>>> not state a goal rather than setting some arbitrary period not  
>>>> based upon any information or rationale.
>>>
>>> The goal is stated. If it needs to be clarified we should do that.
>>
>> DNSBL operators should mimic Spamhaus policies?  Don't suggest  
>> there is some magic period.
>
> Our belief: There needs to be a sensible maximum time of listing  
> should the entry no longer meet the listing criteria.
>
> We think 6 months is a sensible maximum. This BCP is in NO WAY  
> suggesting that an IP/range shouldn't ever be listed for longer  
> than 6 months, but that if your listing criteria is no longer met  
> then the entry should time out after a maximum of 6 months.

6 months is not a sensible maximum in may cases.   If an interval  
must be mentioned, why not say a year or less.  A year is likely to  
be a typical interval for service purchases.  Most spam sources are  
compromised systems.  Increasing the block cycle rate will just  
increase the number of times a compromised system can spew spam  
before being once again blocked.  When the owner of the IP address  
actually wants to send valid email, they can make a request to  
expedite a removal process in most cases.  What makes 6 months sound  
reasonable????

> Clearly we can state this better. I'll try and get Nick to use  
> something from the above paragraph.
>
>>>> Publicly listed messages likely represent a sacrificial source.  
>>>> There lies the rub.  What happens when a spammer has an above  
>>>> average IQ?  Your listed, but we can show you why?
>>>
>>> Do you have an objection to this point being a SHOULD? Clearly  
>>> DNSBLs maintain and even display audit trails and retain  
>>> effectiveness. I'm lost by your argument here. The point of this  
>>> section is that an audit trail is a valuable thing when there's a  
>>> complaint about a listing, or some other issue, so even if it's  
>>> not public the audit trail really should exist.
>>
>> An audit trail should exist.  There are considerations not covered  
>> in this draft about what can be made public.  Those considerations  
>> should be included.  This could brace users when they hear  
>> something that they don't want to hear.  "I can't show you the  
>> message."
>
> Good point. How about:
>
>    A DNSBL SHOULD maintain an audit trail for all listings and it is
>    RECOMMENDED that it is made publicly available in an easy to find
>    location, preferably on the DNSBL's web site.  Please note that
>    making audit trail data public does not entail revealing all
>    information in the DNSBL administrator's possession relating to the
>    listing; e.g., a DNSBL administrator MAY make the audit trail data
>    selectively accessible in such a way as to not disclose information
>    that might assist spammers, such as the contents of an email  
> received
>    by the DNSBL's spam trap.

Better. Chris is right about changing to "a DNSBL spam trap".

-Doug

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Matt Sergeant-2]

On 12-Feb-07, at 2:11 PM, Douglas Otis wrote:

> 6 months is not a sensible maximum in may cases.   If an interval  
> must be mentioned, why not say a year or less.  A year is likely to  
> be a typical interval for service purchases.  Most spam sources are  
> compromised systems.  Increasing the block cycle rate will just  
> increase the number of times a compromised system can spew spam  
> before being once again blocked.  When the owner of the IP address  
> actually wants to send valid email, they can make a request to  
> expedite a removal process in most cases.  What makes 6 months  
> sound reasonable????

6 months is entirely arbitrary. As is your suggestion of "a year or  
less". You have to pick what sounds sensible and that sounded  
sensible to the authors and those who run public DNSBLs that we  
consulted.


_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Chris Lewis-2]

Douglas Otis wrote:

>
> On Feb 12, 2007, at 9:16 AM, Matt Sergeant wrote:
>
>> On 9-Feb-07, at 9:03 PM, Douglas Otis wrote:
>>
>>>>> A period that represents typical IP ownership is not likely 6
>>>>> months.  Many of these systems are compromised and can be retasked
>>>>> to send spam once the IP address drops off a popular block list.
>>>>> How is 6 months reasonable for a long listing?  Why not state a
>>>>> goal rather than setting some arbitrary period not based upon any
>>>>> information or rationale.
>>>>
>>>> The goal is stated. If it needs to be clarified we should do that.
>>>
>>> DNSBL operators should mimic Spamhaus policies?  Don't suggest there
>>> is some magic period.
>>
>> Our belief: There needs to be a sensible maximum time of listing
>> should the entry no longer meet the listing criteria.
>>
>> We think 6 months is a sensible maximum. This BCP is in NO WAY
>> suggesting that an IP/range shouldn't ever be listed for longer than 6
>> months, but that if your listing criteria is no longer met then the
>> entry should time out after a maximum of 6 months.
>
> 6 months is not a sensible maximum in may cases.   If an interval must
> be mentioned, why not say a year or less.  A year is likely to be a
> typical interval for service purchases.  Most spam sources are
> compromised systems.  Increasing the block cycle rate will just increase
> the number of times a compromised system can spew spam before being once
> again blocked.  When the owner of the IP address actually wants to send
> valid email, they can make a request to expedite a removal process in
> most cases.  What makes 6 months sound reasonable????

We have to remember that DNSBLs have very widely varying expiration
intervals, based upon how they list and in some cases sheer size.
SpamCop's initial expiration is a day or two.  But some DNSBLs are forever.

I believe that listings, absent "later redetection of malicious
behaviour", should have a timeout.  For a SBL-ish list, 6 months of "no
repeat behaviour" is a reasonable max.  For a "straight compromise"
DNSBL (like CBL, ORDB etc) it hardly makes sense to hold entries so
long, especially when so much of it is dynamic, or at least, not nearly
as long lived as a stationary MTA.

But aside from things like geo-based DNSBLs, I think all DNSBLs should
have some sort of timeout (again, absent repeat detections).  Otherwise,
we litter IPv4 with IP space that's difficult to use.  I pity the poor
people who have to reuse AGIS space...

I don't think we want to litter the BCP with stuff like that.  I'd like
to avoid it.  But I think saying that a reasonable timeout is a good
idea.  Matt's altered wording is better I think.

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Daniel Feenberg]

On Mon, 12 Feb 2007, Matt Sergeant wrote:

> On 9-Feb-07, at 9:03 PM, Douglas Otis wrote:
>

...

>>>> Publicly listed messages likely represent a sacrificial source.  There
>>>> lies the rub.  What happens when a spammer has an above average IQ?  Your
>>>> listed, but we can show you why?
>>>
>>> Do you have an objection to this point being a SHOULD? Clearly DNSBLs
>>> maintain and even display audit trails and retain effectiveness. I'm lost
>>> by your argument here. The point of this section is that an audit trail is
>>> a valuable thing when there's a complaint about a listing, or some other
>>> issue, so even if it's not public the audit trail really should exist.
>>
>> An audit trail should exist.  There are considerations not covered in this
>> draft about what can be made public.  Those considerations should be
>> included.  This could brace users when they hear something that they don't
>> want to hear.  "I can't show you the message."
>
> Good point. How about:
>
>  A DNSBL SHOULD maintain an audit trail for all listings and it is
>  RECOMMENDED that it is made publicly available in an easy to find
>  location, preferably on the DNSBL's web site.  Please note that
>  making audit trail data public does not entail revealing all
>  information in the DNSBL administrator's possession relating to the
>  listing; e.g., a DNSBL administrator MAY make the audit trail data
>  selectively accessible in such a way as to not disclose information
>  that might assist spammers, such as the contents of an email received
>  by the DNSBL's spam trap.
>
> Matt.
>
>
>

I think there is positive value in diversity of audit trail policy. If all
DNSBLs have no audit trail, then spammer's can't listwash, but it is also
true that operators of websites and MTAs with security problems will not
receive useful information about what is going wrong, and this may
delay corrections. If for instance, a webmaster is responsible for
multiple web pages that generate email, and only one is defective, it
helps to know which one.

If some DNSBLs have detailed audit information available that will help
such sources, without giving spammer's the ability to listwash all
spamtraps.

Since the best outcome is achived by a mix of policies, it hardly seems
necessary to anoint one as "best".

Daniel Feenberg


_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Douglas Otis]

On Feb 12, 2007, at 12:14 PM, Daniel Feenberg wrote:

>
>
> On Mon, 12 Feb 2007, Matt Sergeant wrote:
>
>> On 9-Feb-07, at 9:03 PM, Douglas Otis wrote:
>>
>> Good point. How about:
>>
>> A DNSBL SHOULD maintain an audit trail for all listings and it is  
>> RECOMMENDED that it is made publicly available in an easy to find  
>> location, preferably on the DNSBL's web site.  Please note that  
>> making audit trail data public does not entail revealing all  
>> information in the DNSBL administrator's possession relating to  
>> the  listing; e.g., a DNSBL administrator MAY make the audit trail  
>> data  selectively accessible in such a way as to not disclose  
>> information  that might assist spammers, such as the contents of  
>> an email received  by the DNSBL's spam trap.
>
> I think there is positive value in diversity of audit trail policy.  
> If all DNSBLs have no audit trail, then spammer's can't listwash,  
> but it is also true that operators of websites and MTAs with  
> security problems will not receive useful information about what is  
> going wrong, and this may delay corrections. If for instance, a  
> webmaster is responsible for multiple web pages that generate  
> email, and only one is defective, it helps to know which one.
>
> If some DNSBLs have detailed audit information available that will  
> help such sources, without giving spammer's the ability to listwash  
> all spamtraps.
>
> Since the best outcome is achived by a mix of policies, it hardly  
> seems necessary to anoint one as "best".

I read "selectively accessible" as meaning both trap and content  
redaction.  This means clever spammers may not produce an audit trail  
visible to the public.  It might be good to mention this somewhere.

-Doug

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Douglas Otis]

On Feb 12, 2007, at 11:42 AM, Matt Sergeant wrote:

> On 12-Feb-07, at 2:11 PM, Douglas Otis wrote:
>
>> 6 months is not a sensible maximum in may cases.   If an interval  
>> must be mentioned, why not say a year or less.  A year is likely  
>> to be a typical interval for service purchases.  Most spam sources  
>> are compromised systems.  Increasing the block cycle rate will  
>> just increase the number of times a compromised system can spew  
>> spam before being once again blocked.  When the owner of the IP  
>> address actually wants to send valid email, they can make a  
>> request to expedite a removal process in most cases.  What makes 6  
>> months sound reasonable????
>
> 6 months is entirely arbitrary. As is your suggestion of "a year or  
> less". You have to pick what sounds sensible and that sounded  
> sensible to the authors and those who run public DNSBLs that we  
> consulted.

A year is likely to be a typical interval for bulk service  
agreements.  Why not punish negligent network providers?  Why should  
providers be able to assume their negligence will be quickly expunged?

A period regarding IP address acquisition offers a valid basis for  
some conditioned maximal value.  What justification, beyond the  
SpamHaus policy, is available?

Why not seven years as used by Fair Credit Reporting Act?  Longer  
periods are more likely to ensure future abuse is prevented.  Credit  
agencies are not required to even generate reports in less than one  
year without compensation.  A provider's negligence then hurting next  
year's customer seems like a good incentive to ensure abuse is  
quickly stopped.  There are ample tools available to track abuse  
emerging from a network.  Affecting the bottom line offers powerful  
corrective incentives.  The AGIS address space has been impaired by  
the number of blocks made using BGP.  This is an example where some  
blocks will be very long, complete, and appropriately reflect prior  
negligence.

Why not hold the provider's accountable beyond a typical contract  
period?  Why suggest a BCP that takes the sting out of negligence?

-Doug







_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Matt Sergeant-2]

On 12-Feb-07, at 5:28 PM, Douglas Otis wrote:

> A year is likely to be a typical interval for bulk service agreements.

I'm not sure why you keep persisting on this point. If the criteria  
for the DNSBL is something like "a known spammer has service on this  
IP/range" then after (or before) the timeout period the DNSBL must re-
check that the spammer still has service on that IP/range, and  
confirm that indeed the spammer does. Thus the listing is extended  
beyond the 6 month period. It could last forever for all we care, as  
long as the listing criteria STILL EXISTS.

I'll repeat myself again: this BCP in NO WAY forces delisting after  
the timeout period. It makes that clear - you just choose not to read  
that part for some reason.

I'm done arguing this with you now. We'll discuss between the authors  
if we think 6 months is the wrong time period but you haven't  
presented any decent argument for it IMHO.



_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Douglas Otis]

On Feb 12, 2007, at 7:46 PM, Matt Sergeant wrote:

> On 12-Feb-07, at 5:28 PM, Douglas Otis wrote:
>
>> A year is likely to be a typical interval for bulk service  
>> agreements.
>
> I'm not sure why you keep persisting on this point. If the criteria  
> for the DNSBL is something like "a known spammer has service on  
> this IP/range" then after (or before) the timeout period the DNSBL  
> must re-check that the spammer still has service on that IP/range,  
> and confirm that indeed the spammer does. Thus the listing is  
> extended beyond the 6 month period. It could last forever for all  
> we care, as long as the listing criteria STILL EXISTS.

There are at least two entities to be considered with respect to a  
reasonable listing duration.  One might be the individual entity  
administering the system directly associated with the IP address.  
Another would be the entity providing the IP address and routing from  
their ASN.  The duration of any listing must consider the behavior of  
_both_.  A high density of bad actors within an ASN SHOULD extend  
duration well into a year and be sure to cover a typical contract  
period.   The goal of the DNSBL operator is often to alter the  
behavior of the network provider.  In such cases it is pointless to  
focus upon individual IP addresses when the network provider is truly  
negligent.

> I'll repeat myself again: this BCP in NO WAY forces delisting after  
> the timeout period. It makes that clear - you just choose not to  
> read that part for some reason.
>
> I'm done arguing this with you now. We'll discuss between the  
> authors if we think 6 months is the wrong time period but you  
> haven't presented any decent argument for it IMHO.

On the contrary.  You have not presented cogent arguments as to why 6  
months is a suitable listing duration, especially when a provider is  
negligent.  Individual treatment of IP addresses must be predicated  
upon the provider enforcing an AUP policy that precludes spamming.  
Any provider that offers unlimited services to spammers should never  
expect IP address delisting within an interval as short as 6 months.  
This is being far to generous.  In the case of individual IP  
addresses within a well managed ASN, a request can be made to  
expedite delistings.  Again, when the typical contract is by the  
year, automatic delisting within six months is still likely too soon.

While a six month duration might be selected as a means to reduce  
delisting requests, a poorly managed ASN should still delay a  
delisting over a much longer period.  Incidents of abuse can not  
always be considered by individual IP addresses, but in conjunction  
with the ASN as a whole.

Please don't say this should be based upon what _sounds_ reasonable.  
Perspectives differ between network and email providers, and those  
operating DNSBLs.  The goal of DNSBL operators is to reduce the tide  
of spam, which ironically is not always a shared motivation,  
especially when charges are by bits per second.

-Doug



_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Matt Sergeant-2]

On 13-Feb-07, at 12:57 AM, Douglas Otis wrote:

> There are at least two entities to be considered with respect to a  
> reasonable listing duration.  One might be the individual entity  
> administering the system directly associated with the IP address.  
> Another would be the entity providing the IP address and routing  
> from their ASN.  The duration of any listing must consider the  
> behavior of _both_.  A high density of bad actors within an ASN  
> SHOULD extend duration well into a year and be sure to cover a  
> typical contract period.   The goal of the DNSBL operator is often  
> to alter the behavior of the network provider.  In such cases it is  
> pointless to focus upon individual IP addresses when the network  
> provider is truly negligent.

Nothing in this draft prevents this.

> Individual treatment of IP addresses must be predicated upon the  
> provider enforcing an AUP policy that precludes spamming.  Any  
> provider that offers unlimited services to spammers should never  
> expect IP address delisting within an interval as short as 6  
> months.  This is being far to generous.  In the case of individual  
> IP addresses within a well managed ASN, a request can be made to  
> expedite delistings.  Again, when the typical contract is by the  
> year, automatic delisting within six months is still likely too soon.

Nothing in this draft prevents this.

> While a six month duration might be selected as a means to reduce  
> delisting requests, a poorly managed ASN should still delay a  
> delisting over a much longer period.  Incidents of abuse can not  
> always be considered by individual IP addresses, but in conjunction  
> with the ASN as a whole.

Nothing in this draft prevents this.



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg