Chris Thielen wrote:
Thanks for the response.
Benny Pedersen wrote:
1.4 SPF_SOFTFAIL SPF: sender does not match SPF record
(softfail)
[SPF failed: Please see
http://spf.pobox.com/why.html?sender=blahblahblah]
update Mail::SPF::Query
domain is not pobox but openspf
duly noted... I am using debian sarge which has version 1.997-2, so
unless there are other major problems I'll just live with an older
version right now.
This version of Mail::SPF::Query has no bearing on the configuration
problem.
On Wed, August 16, 2006 18:16, Chris Thielen wrote:
CoWorker (dialup) --> mail server (office) <-- fetchmail (home) <--
you can make fetchmail so it does not add the its own recieved headers
I tried this just now and found that removing the fetchmail headers
doesn't change the received header parsing. The fetchmail headers are
being ignored because they are found outside the trusted area.
[2866] dbg: received-header: found fetchmail marker outside trusted
area, ignored
[2866] dbg: received-header: parsed as [ ip=24.245.33.51
rdns=c-24-245-33-51.hsd1.mn.comcast.net helo=c-24-245-33-51.hsd1.mn.comcast
.net by=mywork.com ident= envfrom= intl=0 id= auth= ]
If the fetchmail headers are being ignored then your trust path isn't
configured right, even to that relay, so you've got no chance at fixing
anything beyond that until you get that taken care of.
You need to trust the following (don't bother even setting internal
networks):
- you server (private and public IPs are good)
- your MXes if any
- you office mail server
After that, hopefully your coworker's submission relay is leaving auth
tokens that will further extend your trust path. If it's not (which
looks like is the case) then, iff your office mail server is only a
submission server and not an incoming MX you can use this patch [1] and
configure that server IP using msa_networks.
[1] http://people.apache.org/~dos/sa-patches/msa_networks.3.1
Daryl
