You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Chris Thielen <cm...@someone.dhs.org> on 2006/08/16 18:16:35 UTC
fetchmail and HELO_DYNAMIC_IPADDR when sender is local
I am using fetchmail to retrieve messages from my work account.
However, messages sent to my work account from coworkers are being
tagged with various dynamic IP rules. My setup is something like this:
CoWorker (dialup) --> mail server (office) <-- fetchmail (home) <--
spamassassin
When a message of this sort is retrieved, I get these rule hits:
4.2 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr
1)
1.4 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
[SPF failed: Please see http://spf.pobox.com/why.html?sender=blahblahblah]
-2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1%
[score: 0.0000]
2.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP
address
[24.245.33.51 listed in dnsbl.sorbs.net]
1.9 RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP
[24.245.33.51 listed in combined.njabl.org]
-0.1 AWL AWL: From: address is in the auto white-list
From reading this thread:
http://thread.gmane.org/gmane.mail.spam.spamassassin.general/83423/focus=83423
it looks like there isn't a simple workable solution. It seems like the
sender is in the right by sending mail through my work's SMTP server
(the problem would go away if they sent through a relay first, but I
can't dictate how people send messages TO me). As Raimar tried in the
thread above, I added my work server to trusted_networks, and
internal_networks but that's not the right way to handle this, apparently.
Is there a workable solution that doesn't require me to whitelist all my
coworker's IP ranges?
Chris
Re: fetchmail and HELO_DYNAMIC_IPADDR when sender is local
Posted by jdow <jd...@earthlink.net>.
From: "Chris Thielen" <cm...@someone.dhs.org>
>I am using fetchmail to retrieve messages from my work account.
> However, messages sent to my work account from coworkers are being
> tagged with various dynamic IP rules. My setup is something like this:
>
> CoWorker (dialup) --> mail server (office) <-- fetchmail (home) <--
> spamassassin
>
>
>
> When a message of this sort is retrieved, I get these rule hits:
>
> 4.2 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr
> 1)
> 1.4 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
> [SPF failed: Please see http://spf.pobox.com/why.html?sender=blahblahblah]
> -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1%
> [score: 0.0000]
> 2.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP
> address
> [24.245.33.51 listed in dnsbl.sorbs.net]
> 1.9 RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP
> [24.245.33.51 listed in combined.njabl.org]
> -0.1 AWL AWL: From: address is in the auto white-list
>
>
>
>
> From reading this thread:
> http://thread.gmane.org/gmane.mail.spam.spamassassin.general/83423/focus=83423
>
> it looks like there isn't a simple workable solution. It seems like the
> sender is in the right by sending mail through my work's SMTP server
> (the problem would go away if they sent through a relay first, but I
> can't dictate how people send messages TO me). As Raimar tried in the
> thread above, I added my work server to trusted_networks, and
> internal_networks but that's not the right way to handle this, apparently.
>
> Is there a workable solution that doesn't require me to whitelist all my
> coworker's IP ranges?
For brute force solutions you could use whitelist_from_rcvd. But even that
is "awkward". Is your office server on your trusted list?
{^_^}
Re: fetchmail and HELO_DYNAMIC_IPADDR when sender is local
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
Chris Thielen wrote:
> So it seems the root of my problem is that users are connecting to the
> office smtp server (also our primary MX) without authentication. That
> seems to be a legitimate hit for the dynamic ip lists. However it is
> also the only legitimate smtp server for these people to use. I guess
> the fix is to *require* authentication for users, but then I don't think
> I could use that same server for MX.
People on random dynamic addresses are connecting to the service without
auth and using it as an MSA?! That's not good. In fact it sounds like
one big open relay.
There's no problem with having people using auth when connecting with
their MUAs expecting MSA services and having the server act as an MX.
Lots of small setups do it this way.
> I guess for now I'll continue to use the hack-ish workaround that munges
> the headers to indicate an authenticated connection even though it's not
> really authenticated.
That sounds like it's prone to false positives when a spammer forges
your from domain/etc.
If you're not sure, if you want to provide a copy of the headers from a
"should be auth'd" connection and headers from mail from a random
"external domain" I'll take a look.
Daryl
Re: fetchmail and HELO_DYNAMIC_IPADDR when sender is local
Posted by Logan Shaw <ls...@emitinc.com>.
On Thu, 17 Aug 2006, Chris Thielen wrote:
> So it seems the root of my problem is that users are connecting to the office
> smtp server (also our primary MX) without authentication. That seems to be a
> legitimate hit for the dynamic ip lists. However it is also the only
> legitimate smtp server for these people to use. I guess the fix is to
> *require* authentication for users, but then I don't think I could use that
> same server for MX.
No, you can. You can tell sendmail (assuming it's sendmail)
to accept a message if it's authenticated OR if the recipient
is local.
If I recall correctly, the way this works is that sendmail by
default understand the "if it's for a user at a local domain,
accept it" part. Then all you have to do is add authentication
for users and it understands the other part as well.
If you want local users inside your office LAN to be able to
send out messages for other people, then you can add some
entries to /etc/mail/access like this:
192.168.1 RELAY
192.168.2 RELAY
192.168.3 RELAY
192.168.4 RELAY
Then, whenever someone connects from, say, 192.168.2.99,
even without authenticating they can send to anybody and the
server will relay it. But if someone connects from 10.20.30.40
without authenticating, sendmail will only deliver the message
if it's local.
Basically, by default you give want to give people access to
do nothing but submit messages that will be delivered locally
on the server. Then, people connecting from the wide open
Internet will be able to do that, but won't be able to relay
through your machine. Then anyone who authenticates or anyone
who is on a local, trusted network can send messages that are
destined for elsewhere and will be relayed by the mail server.
- Logan
Re: fetchmail and HELO_DYNAMIC_IPADDR when sender is local
Posted by Chris Thielen <cm...@someone.dhs.org>.
Oooh, reply to multiple emails at once? I so craaaazy!
jdow wrote:
>
> For brute force solutions you could use whitelist_from_rcvd. But even
> that
> is "awkward". Is your office server on your trusted list?
Yeah, I tried with and without the office server on the trusted list
with no apparent change.
Daryl C. W. O'Shea wrote:
> On Wed, August 16, 2006 18:16, Chris Thielen wrote:
>>> CoWorker (dialup) --> mail server (office) <-- fetchmail (home) <--
>>
>> 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.
Understood...
>
> 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
That is precisely how I have my trusted_networks configured.
>
> 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
So it seems the root of my problem is that users are connecting to the
office smtp server (also our primary MX) without authentication. That
seems to be a legitimate hit for the dynamic ip lists. However it is
also the only legitimate smtp server for these people to use. I guess
the fix is to *require* authentication for users, but then I don't think
I could use that same server for MX.
I guess for now I'll continue to use the hack-ish workaround that munges
the headers to indicate an authenticated connection even though it's not
really authenticated.
Re: fetchmail and HELO_DYNAMIC_IPADDR when sender is local
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
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
Re: fetchmail and HELO_DYNAMIC_IPADDR when sender is local
Posted by Chris Thielen <cm...@someone.dhs.org>.
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.
> 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= ]
I am going to work around the problem for now with a procmail recipe. I
am going to munge the received headers and replace the "with SMTP" to a
false authenticated header. That isn't a pretty solution, nor reliable,
but it will serve my purposes for now.
Thanks for listening
Re: fetchmail and HELO_DYNAMIC_IPADDR when sender is local
Posted by Benny Pedersen <me...@junc.org>.
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
> 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
--
Benny