Re: SPF and bouncing

ok so basically your wanting to add stuff to spf because you want an easier way to do goldlisting
(seems to be the crux here)
so your assuming anyone wanting to talk to your goldlisting implementation will
choose to use your new spf (if they use batv/verp
care to pass your filters

both i think are unlikely, better to design (like the rest of us do) a system that works with ALL current mailers, but works better/faster and with less chance of false positive on those that adopt spf/csv/dkim/etc/etc.

At 13:30 07/05/2012  Monday, Michael Deutschmann wrote:
>On Fri, 4 May 2012, alan wrote:
>> whitelisting VERP senders is common and easy, or no 'goldlister' could
>> ever subscribe to any mailinglist,
>
>I wouldn't quite call whitelisting mailinglists a solved problem yet.  I
>do it, but it's a hack that occasionally fails.  The key problem is that
>for many mailing lists, including this one, the MAIL FROM: domain of the
>distributed messages ("jeeves.archive.listbox.com") is not the same as
>that of the submission address ("listbox.com").  The former sometimes
>changes abruptly (this list was "v2.listbox.com" before 2007).
>
>> simply accept mail from *@whitelinsted-domain at rcpt (assuming spf
>> pass /helo/ptr/dnsbl etc.) then check for From: Sender: etc containing
>> whitelisted-sender@whitelisted-domain at data (and if from non-whitelisted
>> neighbour reject)
>
>That lets too much stuff through to DATA.

if your gold listing you have no choice, you cant 'demand' that 'large-isp-using-batv' start adopting your 'fork' or extension to spf, simply put like spfv1 most just wont (many havn't yet adopted the simple current spf)

>True, an expert user with access to logs can recognize VERP and manually
>tell his server to demangle the addresses coming from that site.  But I
>want to aim higher and make whitelisting work for more casual users, by
>making the demangling instructions *public*.
>
>> spf is a tool for sender validation, and expression of the senders
>> policy of what should happen to invalidated mails, it has no place for
>> specifying the senders wilingness or unwillingness to receive/refuse
>> bounces, and shouldn't
>
>You're attacking the wrong prong of my fork here.  I'm discussing a
>proposal to but a flag in SPF records advertising that VERP is in use and
>a defined way to decode it.   Thus allowing the recipient to obtain the
>whitelist lookup key without going to DATA.

not spf's issue, spf has validated it came from the right ip's to be non-forged (job done)

your goldlisting and resource consumption of same is not spfs issue
(you have to let it goto data to accept from [for example yahoo] as you can only forgery reject them after dkim as they dont use spf at all)

if YOU require a way to pre-data verify the email address of the sender's reply-to or from header
(considering for many forms of batv this cannot be done without access to their servers db/lookup table as their is no simple key)
consider writing your own RFC/Protocol to do so
such as lookup TXT _verpdecode.envelope-sender-domain
for a (to be invented by you) code to decode their reversible verp (if they use a reversible verp)
plus some sort of way for them to signal their verp cant be reversed
plus some way for them to offer a port/server to 'finger' with the encoded address to receive the decoded sender if non reversible


>(The fork is because we cannot reach agreement on whether deliveries
>coming from a site with a "?a -all" SPF record are absolutely
>irreversible, not even for quota problems.

bounces for as i said quota issues (if properly limited) are always acceptable
(ie more so than nether side being informed of the mail dissapearing into the void)

>If one thinks so (as I do), then a qualifier that says "just as much
>confidence the message is unforged as pass, however bounces are still as
>unacceptable as if neutral" is needed.  It would belong in SPF because it
>would be *fixing* an unwanted connotation of regular SPF pass.

if your system is bouncing because of later checks that should have been done before the 200 at end of data then yes they are unacceptable/illegitimate and an abuse  
just fix the checks to happen before the 200
(regardless of -all ~all ?all or no spf at all)

the corollary of this is that if any system generates legitimate bounces after accepting legitimate un forged mail(due to quota etc) then those bounces should NOT be suppressed due to some unwillingness of the sender to process them, and thus no extension should be made for senders to ask receivers to suppress legitimate bounces.
 
suppressing legitimate bounces like /dev/nulling mail is bad for all senders and receivers alike

making it possible for receivers to lazily filter (after accepting) but /dev/null NDRs instead of rejecting and having the sender notified is unhealthy for the ecosystem
it also causes dirty senders (who allowed forged mail out) to not generate NDRs (as they dont get a reject) that would otherwise allow the rest of us to track and thus lower their reputations

>If one thinks not (as you, Alan, do), then the qualifier is pointless, but
>now we will need VERP, and thus measures to stop VERP from poisoning
>whitelisting.  This belongs in SPF because SPF depends on whitelisting to
>avoid being abused by spammers who generate publish SPF records on their
>throwaway domains.)

spf dosn't rely on whitelisting?
spf is not an anti spam technology
spf is ONLY an anti forgery technology

spammers that publish spf was always expected whitelisting/goldlisting is not the answer, most who do look for an answer simply require sending ips/domains to be on a reputation list (most don't even require spf)

but no one wants spf to become something more than what it is, better/quicker/bug-freer maybe.