On Sun, May 27, 2012 at 7:19 PM, Peter N. M. Hansteen <[email protected]> wrote: > David Diggles <[email protected]> writes: > >> Or did you mean, this breaks spamlogd, rather? >> >> pass in on egress proto tcp from any to egress \ >> port smtp rdr-to 127.0.0.1 port spamd synproxy state >> >> This is what it was. The logging is on now. > > The important ones to log are the rules that pass smtp traffic from the > members of the spamd-white table (and nospamd if you're using that) plus > the one that passes smtp traffic from your real mail server to > elsewhere. See the spamd and spamlogd man pages, it's explained there. > > But why are you synproxying for spamd? > > - P > -- > 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. >
Perhaps off-topic, but I've been working under the assumption that synproxy (or some portion thereof) has been broken for the last few releases. Whether or not it was actually useful to my configuration, enabling synproxy shouldn't hurt anything, right? Because switching from synproxy to modulate state seemed to fix intermittent download issues for Windows machines sitting behind my pf NAT. Never had an issue on the OpenBSD device itself, FWIW. Can anyone confirm with better-than-anecdotal knowledge? --david
