SPF Unblocking

When I get entries in spf.log like:

Successful allow received <allow-uj3k-193.227.251.22mdcclxxvi.com> - 
ip (193.227.251.22) unblocked
Successful allow received <allow-hca2-122.168.91.165mdcclxxvi.com> - 
ip (122.168.91.165) unblocked
Successful allow received <allow-eaud-125.26.123.111mdcclxxvi.com> - 
ip (125.26.123.111) unblocked
Successful allow received <allow-4cqx-190.56.41.165mdcclxxvi.com> - 
ip (190.56.41.165) unblocked
Successful allow received <allow-7jsq-122.2.150.207mdcclxxvi.com> - 
ip (122.2.150.207) unblocked
Successful allow received <allow-9cnl-217.146.242.107mdcclxxvi.com> 
- ip (217.146.242.107) unblocked
Successful allow received <allow-62uw-89.33.3.42mdcclxxvi.com> - ip 
(89.33.3.42) unblocked
Successful allow received <allow-0lyw-88.201.128.69mdcclxxvi.com> - 
ip (88.201.128.69) unblocked

What happened to unblock the IPs?

Most of the unblocked IPs seem like spam sources, based on a
DNS 
lookup -- having either no host name associated with the
address or 
an obvious end user/dynamic IP.

This means they have responded to an allow email, if you
suspect this is becoming extremely common then you can
change 
to the web based allow mechanism instead.
	g_spf_byweb "true"

I doubt this step is really necessary though.

The other thing that would be interesting would be to search
the msg*.rec logs for the same period for the ip address
in question and see how long the delay was before the allow
email arrived from when the original email was bounced.


	ChrisP.


Warren Michelsen wrote:
> When I get entries in spf.log like:
> 
> Successful allow received
<allow-uj3k-193.227.251.22mdcclxxvi.com> - ip 
> (193.227.251.22) unblocked
> Successful allow received
<allow-hca2-122.168.91.165mdcclxxvi.com> - ip 
> (122.168.91.165) unblocked
> Successful allow received
<allow-eaud-125.26.123.111mdcclxxvi.com> - ip 
> (125.26.123.111) unblocked
> Successful allow received
<allow-4cqx-190.56.41.165mdcclxxvi.com> - ip 
> (190.56.41.165) unblocked
> Successful allow received
<allow-7jsq-122.2.150.207mdcclxxvi.com> - ip 
> (122.2.150.207) unblocked
> Successful allow received
<allow-9cnl-217.146.242.107mdcclxxvi.com> - 
> ip (217.146.242.107) unblocked
> Successful allow received <allow-62uw-89.33.3.42mdcclxxvi.com> - ip 
> (89.33.3.42) unblocked
> Successful allow received
<allow-0lyw-88.201.128.69mdcclxxvi.com> - ip 
> (88.201.128.69) unblocked
> 
> What happened to unblock the IPs?
> 
> Most of the unblocked IPs seem like spam sources, based
on a DNS lookup 
> -- having either no host name associated with the
address or an obvious 
> end user/dynamic IP.
> 
> 
> 
> 

At 10:04 AM +1300 1/14/08, Support ChrisP sent email
regarding Re: 
[SurgeMail List] SPF Unblocking:
>This means they have responded to an allow email, if you
suspect 
>this is becoming extremely common then you can change to
the web 
>based allow mechanism instead.
>	g_spf_byweb "true"
>
>I doubt this step is really necessary though.

Necessary? I dunno. Most every IP which has been unblocked
is caught 
by an RBL or some such.

>
>The other thing that would be interesting would be to
search the 
>msg*.rec logs for the same period for the ip address in
question and 
>see how long the delay was before the allow email
arrived from when 
>the original email was bounced.

It would sure be nice if the msg*.rec logs could be searched
from the 
Logs web admin page.

>
>
>	ChrisP.
>
>
>Warren Michelsen wrote:
>>When I get entries in spf.log like:
>>
>>Successful allow received
<allow-uj3k-193.227.251.22mdcclxxvi.com> 
>>- ip (193.227.251.22) unblocked
>>Successful allow received
<allow-hca2-122.168.91.165mdcclxxvi.com> 
>>- ip (122.168.91.165) unblocked
>>Successful allow received
<allow-eaud-125.26.123.111mdcclxxvi.com> 
>>- ip (125.26.123.111) unblocked
>>Successful allow received
<allow-4cqx-190.56.41.165mdcclxxvi.com> 
>>- ip (190.56.41.165) unblocked
>>Successful allow received
<allow-7jsq-122.2.150.207mdcclxxvi.com> 
>>- ip (122.2.150.207) unblocked
>>Successful allow received 
>><allow-9cnl-217.146.242.107mdcclxxvi.com> - ip
(217.146.242.107) 
>>unblocked
>>Successful allow received
<allow-62uw-89.33.3.42mdcclxxvi.com> - 
>>ip (89.33.3.42) unblocked
>>Successful allow received
<allow-0lyw-88.201.128.69mdcclxxvi.com> 
>>- ip (88.201.128.69) unblocked
>>
>>What happened to unblock the IPs?

At 10:04 AM +1300 1/14/08, Support ChrisP sent email
regarding Re: 
[SurgeMail List] SPF Unblocking:
>This means they have responded to an allow email, if you
suspect 
>this is becoming extremely common then you can change to
the web 
>based allow mechanism instead.
>	g_spf_byweb "true"

That would just make it easier to bypass SPF. As is, when
spf bounces 
one of these, I see the unblock message coming back from
multiple 
IPs, each of which is caught by the RBL list.

>The other thing that would be interesting would be to
search the 
>msg*.rec logs for the same period for the ip address in
question and 
>see how long the delay was before the allow email
arrived from when 
>the original email was bounced.

OK, if I'm in the msg0801 directory, what the Unixy way to
search all 
.rec files in it for a given string?

Warren Michelsen wrote:
> At 10:04 AM +1300 1/14/08, Support ChrisP sent email
regarding Re: 
> [SurgeMail List] SPF Unblocking:
>> This means they have responded to an allow email,
if you suspect this 
>> is becoming extremely common then you can change to
the web based 
>> allow mechanism instead.
>>     g_spf_byweb "true"
> 
> That would just make it easier to bypass SPF. As is,
when spf bounces 
> one of these, I see the unblock message coming back
from multiple IPs, 
> each of which is caught by the RBL list.
> 
>> The other thing that would be interesting would be
to search the 
>> msg*.rec logs for the same period for the ip
address in question and 
>> see how long the delay was before the allow email
arrived from when 
>> the original email was bounced.
> 
> OK, if I'm in the msg0801 directory, what the Unixy way
to search all 
> .rec files in it for a given string?

grep "1.2.3.4" msg*.rec

the log web admin page does search the msg*.rec files,
that's the default file for it to search, you just need to
change the date range to make it search older ones too.

Or use grep as above.


	ChrisP.

Well, this is interesting. I went through my current and one
rolled 
spf.log. Here's what I found.

One (1) address was unclocked just one time -- a msn server.
Very likely legit.

For every other IP address that was unblocked (16 of them),
SM 
received an average 50.68 emails to the address. So, this
looks to me 
like these addresses were being spammed; these were not
legitimate 
unblocking emails. (Often they were from multiple IPs at
different 
domains to the same unblocking address.) Fortunately, it
appears that 
SM, upon receiving a message to the unblocking address,
simply 
unblocks (and logs it) then drops the connection, there
being no 
actual recipient with that account name.

So, there was one legit unlock, 811 spam attempts to the
unlock 
addresses and the spf.log, for the same period, shows 
30,871 
"SPF_NONE and mode==mean so trying a default rule"
entries.

Hmm, ok I've looked into this a bit more and found similar
results, it seems a spam robot of some sort collects
the allow addresses then tries to send spam at them, which
luckily is pointless and harmless, but we will modify the 
hashing slightly so in future it will recognize these and
give 550 errors back instead.

	ChrisP.


Warren Michelsen wrote:
> Well, this is interesting. I went through my current
and one rolled 
> spf.log. Here's what I found.
> 
> One (1) address was unclocked just one time -- a msn
server. Very likely 
> legit.
> 
> For every other IP address that was unblocked (16 of
them), SM received 
> an average 50.68 emails to the address. So, this looks
to me like these 
> addresses were being spammed; these were not legitimate
unblocking 
> emails. (Often they were from multiple IPs at different
domains to the 
> same unblocking address.) Fortunately, it appears that
SM, upon 
> receiving a message to the unblocking address, simply
unblocks (and logs 
> it) then drops the connection, there being no actual
recipient with that 
> account name.
> 
> So, there was one legit unlock, 811 spam attempts to
the unlock 
> addresses and the spf.log, for the same period, shows 
30,871 "SPF_NONE 
> and mode==mean so trying a default rule" entries.
> 
>