|
»
« Return to Thread: DNSBL BCP v.2.0
Re: Re: DNSBL BCP v.2.0
by Matt Sergeant-2
::
Rate this Message:
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.
> ---
> 3.3. Content of DNSBL Zone File SHOULD Be Limited.
>
> The DNSBL "query root" SHOULD be below the registered domain, so
> that the DNSBL information is not conflated with domain housekeeping
> information (e.g., name server, MX or SPF records). By using this
> approach, DNSBL queries would take the form of
> "<query>.dnsbl.example.com" rather than "<query>.example.com".
> ---
>
> This would be a problem only when zone transfers are used to
> distribute
> data.
... which covers all public DNSBLs, surely? Or at least those that
have any hope of becoming popular (i.e. those that follow best
practices). I don't see any reason you'd want to remove this section.
> ---
> There is nothing inherently wrong with this practice so long as it
> is clearly disclosed. For example, a DNSBL described as listing open
> relays only MUST NOT include IP addresses for any other reason. This
> transparency principle does not require DNSBL administrators to
> disclose the precise algorithms and data involved in a listing.
> ---
>
> s/as listing open relays/as only listing open relays/
Good.
> ---
> 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.
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
>> 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.
> ---
> 3.3. Content of DNSBL Zone File SHOULD Be Limited.
>
> The DNSBL "query root" SHOULD be below the registered domain, so
> that the DNSBL information is not conflated with domain housekeeping
> information (e.g., name server, MX or SPF records). By using this
> approach, DNSBL queries would take the form of
> "<query>.dnsbl.example.com" rather than "<query>.example.com".
> ---
>
> This would be a problem only when zone transfers are used to
> distribute
> data.
... which covers all public DNSBLs, surely? Or at least those that
have any hope of becoming popular (i.e. those that follow best
practices). I don't see any reason you'd want to remove this section.
> ---
> There is nothing inherently wrong with this practice so long as it
> is clearly disclosed. For example, a DNSBL described as listing open
> relays only MUST NOT include IP addresses for any other reason. This
> transparency principle does not require DNSBL administrators to
> disclose the precise algorithms and data involved in a listing.
> ---
>
> s/as listing open relays/as only listing open relays/
Good.
> ---
> 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.
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
« Return to Thread: DNSBL BCP v.2.0
| Free embeddable forum powered by Nabble | Forum Help |
