Re: smtpctl spf walk chokes on macros - is it possible to work around this?

2021-03-19 Thread Martijn van Duren
On Fri, 2021-03-19 at 11:46 +0100, Peter N. M. Hansteen wrote:
> Watching indly while I run the script that refreshes my nospamd data[1] I see
> several occurences of messages like
> 
> 
> processing verticalresponse.com
> smtpctl: lookup_record: %{i}._spf.mta.salesforce.com contains macros and 
> can't be resolved
> 
> digging through the dig $domain txt output turns up the salesforce.com record 
> is
> 
> _spf.salesforce.com.3512IN  TXT "v=spf1 
> exists:%{i}._spf.mta.salesforce.com -all"
> 
> is there a way to shoehorn this into something useful in our context?

I don't see how this can be done in a sane way, since the content of
the macro's isn't know at the time of resolving via spf walk.

In this particular case we would have to walk over every single ipv4
and ipv6 ip-address in existence and paste it before
_spf.mta.salesforce.com in order to know which hosts are allowed to
mail from spf.salesforce.com. Not something that's very likely.

*Maybe* there could be some option where we could add something like
`smtpctl spf walk -i 127.0.0.1 verticalresponse.com`, but I guess
that would not be a useful option for you, since you want to know
which hosts are allowed to begin with.

martijn@
> 
> All the best,
> Peter
> 
> [1] Described in 
> https://bsdly.blogspot.com/2018/11/goodness-enumerated-by-robots-or.html
> 





smtpctl spf walk chokes on macros - is it possible to work around this?

2021-03-19 Thread Peter N. M. Hansteen
Watching indly while I run the script that refreshes my nospamd data[1] I see
several occurences of messages like


processing verticalresponse.com
smtpctl: lookup_record: %{i}._spf.mta.salesforce.com contains macros and can't 
be resolved

digging through the dig $domain txt output turns up the salesforce.com record is

_spf.salesforce.com.3512IN  TXT "v=spf1 
exists:%{i}._spf.mta.salesforce.com -all"

is there a way to shoehorn this into something useful in our context?

All the best,
Peter

[1] Described in 
https://bsdly.blogspot.com/2018/11/goodness-enumerated-by-robots-or.html

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.