Re: SPF and bouncing

last post this is just nothing to do with spf

At 02:17 06/05/2012  Sunday, Michael Deutschmann wrote:
>On Sat, 5 May 2012, Alessandro Veseley wrote:
>> > Because the HELO name can be anything, so arranging for an SPF HELO
>> > pass is trivial.
>>
>> You must mean address literals, which are mostly used by MUAs AFAIK.
>
>No, it has nothing to do with [] in addresses.
>
>The problem is that the HELO domain is of no use in determining if an
>incoming MAIL FROM: <> has anything to do with a message you actually
>sent in the past month.

obviously its not spf's job

>gmail.com's MXes and smarthosts are kept within the domain of their
>corporate sponsor, google.com.  If gmail.com were ever to issue a bounce,
>it would likely bear a HELO ending in .google.com.  So a naive algorithm
>that said "let a purported bounce through if the HELO is SPF-approved and
>is equal to or a subdomain of any domain we have mailed to in the past
>month"

that would be a dumb algorithim, and would fail for 99% of all mail
a chance of working one would be
when sending mail from fred@yourdomain cache domains of all mx's(listed for recipient) (in this case xxxx.google.com)
then accept <> from helo's within those domains (if not spf fail) (spf non-users are allowed to legit bounce too) if going to fred@yourdomain

(better would be to parse the body and see if its a legit ndr (as it should normally include the to/from/ and likely your message-id, there are only about 20-70 MTAs in common use and validating legit bounce pattern from most wouldn't be rocket science)

as anyone at anydomain has their mail go via theirprovidersdomain (both in and out)
(those who point mxX.theirdomain at their providers IP break tls so should learn better and point their mxs at the name their provider uses in helo.theirprovidersdomain)

this is why there are billions of domains, yet relatively few valid helo-identities (one per sending and/or recieving mailserver)

either way if really paranoid about not accepting forged mail from <> use batv its what it was designed for!!!

>Drop the "is equal to or a subdomain" requirement, and any spammer who
>wants to exploit the <> loophole will do so using a HELO domain that he
>fully owns.  Then it's trivial for him to engineer a genuine SPF Pass.

and be traceable or on an rbl/dbl

>Thus, for spam control purposes

not spf's job (forgery control is spfs job ONLY)

> it is best to ignore the HELO (aside from
>certain idiot filters), and treat all <> mail as effectively SPF-neutral.

there is vanisingly small amounts of spam with <>

either way its non forged if the helo had valid spf, all non-forged spam gets spf-pass regardless of sender so why would they use <> when they could use blah@spammerdomain and get the same pass

helo pass just shows (with other basic tests like fqrdns etc) that the server IS a server not a bot
(thus killing 98% of connections before looking further) whether mail is from <> or not

if really not happy about bounces, dont send mail
if wanting to authenticate bounces, use batv
if wanting to authenticate bounces but not use batv invent something better (see if anyone uses it)

either way stop trying to make this pet issue spf's fault/responsibility/issue/problem to fix

its way outside the scope of spf, spf deals with allowing senders to publish their sending policy

(no implication is made about whether they even have incoming mail setup for the domain, so why would their bounce acceptance/non-acceptance be added)

i can currently setup [email protected] tomorrow and point its mx's at ips with no MTA and publish an spf that allows me to send validly to anyone, spf dosnt say you can reply/bounce or even if the domain is a valid email, this is down to a myriad of other checks/protocols/dnsbl's
(it isn't a valid email if not capable of receiving obviously)

SPF ONLY expresses the domain owners intent as to where he sends from (pass=verified genuine), and whether non-passes are considered outright-forgeries -/possible-forgeries ~/just-non-verified ?

it is not a fix for any other ailments
it sits with all the other basic tests to compliment them
my own servers do 37 separate tests by rcpt-to, sfp for helo & spf for envelope-sender are just 2 and not the most significant by far.