Matthew Lenz wrote:
ok. i think i got it. what parts of the headers does spamassassin look at
for trusted_networks? my guess is that if there are any untrusted ip's
mentioned in the received: headers it marks it as untrusted?
Yeah, it trusts each received header starting from the top until it finds
an IP that's not in the list of trusted_networks.
what about my pop-before-smtp users? they'll be relaying through the
public ip sending emails to one another on that same machine. how does
it know that isn't a direct MX spam?
Some questions first...
1. do you control the IPs that your dial-up users are connecting from
no.. they all connect from various isp's.
2. does the smtp smarthost that the dial-up users use have the same IP as
the smtp server that is passing the mail to SA or is it different?
they connect to the public ip address which is a 1:1 nat to the private ip
that postfix/SA run on. I just tried it myself. I sent an email from
myself to myself and SA noticed that i connected directly to the smtp server
from an ip in DUL's.
RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL
it wasn't enough to classify it as spam but still kinda worry's me.
previously just had people send work email via their isp smtp servers. but
that doesn't play well with SPF does it? (for future consideration.. i don't
have any spf stuff enabled that I know of)
3. can you obtain enough pain medication to get them all to convert to
auth'd SMTP connections?
heh I thought about implementing it .. maybe i still can at some point.
Daryl
