Unknown senders and spam

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Unknown senders and spam

Alex Regan
Hi,

I'm wondering about some messages with Received headers such as this:

    Received: from zaphod.chipchaps.com (unknown [65.182.186.13])

It says 'unknown', but 65.182.186.13 does resolve, to chipchaps.com (a
spam site), which resolves back to 65.182.186.12. Is this where the
problem is?

I'm not sure if I'm having a DNS problem with my resolver not being
able to find the answer in time (or at all), or I'm possibly not
understanding how to do this properly. I'd like to determine if I can
add additional restrictions in postfix to limit connections from hosts
that don't resolve properly, but before I can do that I need to make
sure my DNS is working properly. Maybe I'm able to resolve it now but
wasn't able to when the email arrived? Maybe the DNS info has changed
since the email was received?

What are the risks or implications of denying messages of this type?

Thanks,
Alex
Reply | Threaded
Open this post in threaded view
|

Re: Unknown senders and spam

Wietse Venema
Alex:
> Hi,
>
> I'm wondering about some messages with Received headers such as this:
>
>     Received: from zaphod.chipchaps.com (unknown [65.182.186.13])
>
> It says 'unknown', but 65.182.186.13 does resolve, to chipchaps.com (a
> spam site), which resolves back to 65.182.186.12. Is this where the
> problem is?

The definition of an "unknown" client hostname is given in
http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname
which, as the name suggests, rejects mail from a client with a hostname
that Postfix considers "unknown".

        Wietse

> I'm not sure if I'm having a DNS problem with my resolver not being
> able to find the answer in time (or at all), or I'm possibly not
> understanding how to do this properly. I'd like to determine if I can
> add additional restrictions in postfix to limit connections from hosts
> that don't resolve properly, but before I can do that I need to make
> sure my DNS is working properly. Maybe I'm able to resolve it now but
> wasn't able to when the email arrived? Maybe the DNS info has changed
> since the email was received?
>
> What are the risks or implications of denying messages of this type?
>
> Thanks,
> Alex
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Unknown senders and spam

Alex Regan
Hi,

>>     Received: from zaphod.chipchaps.com (unknown [65.182.186.13])
>>
>> It says 'unknown', but 65.182.186.13 does resolve, to chipchaps.com (a
>> spam site), which resolves back to 65.182.186.12. Is this where the
>> problem is?
>
> The definition of an "unknown" client hostname is given in
> http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname
> which, as the name suggests, rejects mail from a client with a hostname
> that Postfix considers "unknown".

Is it common practice to have that restriction in a production environment?

It appears to be the third case here, that the name->address mapping
does not match the client IP address. Could this be from a legitimate
cause, or typically intentionally to be evasive?

Could it be found in a legitimate dynamic environment, such as at an ISP?

Is there a way to log these specific failures so I can get a better
idea of under what circumstances they occur in my environment?

I'm currently rejecting the following, in this order:

        reject_non_fqdn_sender,
        reject_non_fqdn_recipient,
        reject_unknown_sender_domain,
        reject_unknown_recipient_domain,
        reject_unauth_pipelining,
        reject_invalid_hostname,
        reject_non_fqdn_hostname,
        reject_unauth_destination,
        reject_maps_rbl,

Thanks,
Alex
Reply | Threaded
Open this post in threaded view
|

Re: Unknown senders and spam

Wietse Venema
Alex:

> Hi,
>
> >> ? ? Received: from zaphod.chipchaps.com (unknown [65.182.186.13])
> >>
> >> It says 'unknown', but 65.182.186.13 does resolve, to chipchaps.com (a
> >> spam site), which resolves back to 65.182.186.12. Is this where the
> >> problem is?
> >
> > The definition of an "unknown" client hostname is given in
> > http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname
> > which, as the name suggests, rejects mail from a client with a hostname
> > that Postfix considers "unknown".
>
> Is it common practice to have that restriction in a production environment?

Yes, if the tolerance for spam is worse than the tolerance for
mail not received.

[speculation deleted]

> Is there a way to log these specific failures so I can get a better
> idea of under what circumstances they occur in my environment?

Postfix logs a warning when the reverse name does not resolve, or
when the reverse name resolves to the wrong address:

    warning: 1.2.3.4: hostname example.com verification failed:
        Host not found, try again
    warning: 1.2.3.4: address not listed for hostname example.com

When you report a problem, it is a good idea to look at the
warning messages in the Postfix logfile.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Unknown senders and spam

mouss-4
In reply to this post by Alex Regan
Alex a écrit :

> Hi,
>
>>>     Received: from zaphod.chipchaps.com (unknown [65.182.186.13])
>>>
>>> It says 'unknown', but 65.182.186.13 does resolve, to chipchaps.com (a
>>> spam site), which resolves back to 65.182.186.12. Is this where the
>>> problem is?
>> The definition of an "unknown" client hostname is given in
>> http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname
>> which, as the name suggests, rejects mail from a client with a hostname
>> that Postfix considers "unknown".
>
> Is it common practice to have that restriction in a production environment?
>
> It appears to be the third case here, that the name->address mapping
> does not match the client IP address. Could this be from a legitimate
> cause, or typically intentionally to be evasive?
>

since they put their domain name in their HELO (zaphod.chipchaps.com),
they're not trying to evade anything.

you could try

        check_client_access hash:/etc/postfix/access_unknown


smtpd_restriction_classes =
        ...
        policy_strong

policy_strong =
        reject_rbl_client bb.barracudacentral.org
        ...

== access_unknown
unknown policy_strong

as usual, use at your own risk! you can try it with warn_if_reject for
some time if that makes you feel more confident
(and no, I don't use such a check).

> Could it be found in a legitimate dynamic environment, such as at an ISP?

no, these are spammers (illegal "work from home"). the domain probably
belongs to "Global Innovative Marketing" as you can find by visiting
their web page (www.chipchaps...) then clicking on the link at the
bottom, which leads you to a privacy page, and if you scroll down, you
get [hidden email]. whois of the latter gives "Global
Innovative Marketing" (both chipchaps and bvconsulting.org have hidden
whois).

anyway,
- www.chipchaps... sis enough to convince you they are spammers.
- they have two IPs (.12 and .13) inside a range of IPs with generic
names belonging to pugmarks.com, who provide hosting...

Also look at Senderbase:
http://www.senderbase.org/senderbase_queries/detailip?search_string=65.182.186.0%2F24

you can probably block the whole range...


>
> Is there a way to log these specific failures so I can get a better
> idea of under what circumstances they occur in my environment?
>
> I'm currently rejecting the following, in this order:
>
>         reject_non_fqdn_sender,
>         reject_non_fqdn_recipient,
>         reject_unknown_sender_domain,
>         reject_unknown_recipient_domain,
>         reject_unauth_pipelining,
>         reject_invalid_hostname,
>         reject_non_fqdn_hostname,
>         reject_unauth_destination,
>         reject_maps_rbl,
>
> Thanks,
> Alex

Reply | Threaded
Open this post in threaded view
|

Re: Unknown senders and spam

Alex Regan
Hi,

>> Is it common practice to have that restriction in a production environment?
>>
>> It appears to be the third case here, that the name->address mapping
>> does not match the client IP address. Could this be from a legitimate
>> cause, or typically intentionally to be evasive?
>>
>
> since they put their domain name in their HELO (zaphod.chipchaps.com),
> they're not trying to evade anything.

Yes, I guess they would have been rejected as a result of my helo checks.

> you could try
>
>        check_client_access hash:/etc/postfix/access_unknown
>
>
> smtpd_restriction_classes =
>        ...
>        policy_strong
>
> policy_strong =
>        reject_rbl_client bb.barracudacentral.org

Is it possible to use maps_rbl_domains instead of reject_rbl_client
here? It appears this machine has a version of postfix that doesn't
understand reject_rbl_client.

Thanks again!
Best regards,
Alex
Reply | Threaded
Open this post in threaded view
|

Re: Unknown senders and spam

Stan Hoeppner
Alex put forth on 4/18/2010 4:45 PM:
> Is it possible to use maps_rbl_domains instead of reject_rbl_client
> here? It appears this machine has a version of postfix that doesn't
> understand reject_rbl_client.

maps_rbl_domains (default: empty)

    Obsolete feature: use the reject_rbl_client feature instead.


reject_rbl_client rbl_domain=d.d.d.d
...
*** This feature is available in Postfix 2.0 and later. ***

(emphasis mine)

Your statement leads me to believe you're using a Postfix version less than
2.0.  IIRC, versions less than 2.3 are no longer supported.

It appears you _really_ need to upgrade Postfix on that host.  And given
that it's likely a distribution package, you probably really need to update
the OS on that host as well.

--
Stan

Reply | Threaded
Open this post in threaded view
|

Re: Unknown senders and spam

Alex Regan
Hi,

> maps_rbl_domains (default: empty)
>
>    Obsolete feature: use the reject_rbl_client feature instead.

Yes, that was why I was asking. It's a really old version of postfix
I'm still using on this host for now, until I can migrate to an
entirely new server and at the same time keep this one running.

I just wanted to confirm that this feature, or an equivalent, isn't
available in old versions of postfix?

Thanks,
Alex
Reply | Threaded
Open this post in threaded view
|

Re: Unknown senders and spam

Wietse Venema
Alex:

> Hi,
>
> > maps_rbl_domains (default: empty)
> >
> > ? ?Obsolete feature: use the reject_rbl_client feature instead.
>
> Yes, that was why I was asking. It's a really old version of postfix
> I'm still using on this host for now, until I can migrate to an
> entirely new server and at the same time keep this one running.
>
> I just wanted to confirm that this feature, or an equivalent, isn't
> available in old versions of postfix?

If in doubt read the documentation.

man 5 postconf
        ...
       reject_rbl_client rbl_domain=d.d.d.d
                ...
              This feature is available in Postfix 2.0 and later.

Reply | Threaded
Open this post in threaded view
|

Re: Unknown senders and spam

/dev/rob0
In reply to this post by Alex Regan
Note: just before sending this I went back to read the rest of
the thread, wherein I see that you're using a pre-2.0 Postfix. Some
of my advice below is thereby not relevant to this host, namely, the
suggestion to use newer syntax and the newer restriction,
reject_unknown_reverse_client_hostname. IMO that would be worth an
upgrade.


On Sun, Apr 18, 2010 at 02:19:15PM -0400, Alex wrote re:
reject_unknown_client_hostname :
> Is it common practice to have that restriction in a production
> environment?

Recently I had a failure of reverse DNS at my colo provider. It went
some days before I was aware of the issue (it's a small site and I
don't monitor the logs.)

When I discovered the issue, I found a lot of mail in the queue, but
few outright 5xx rejections had been done. Temporary rejections were
occurring from numerous large providers, including Gmail, AOL, Yahoo,
and Comcast.

I temporarily shut down outbound mail and set up a relayhost while
the provider fixed the rDNS issues (my PTR query was returning
NXDOMAIN during this time.)

Note, from the documentation suggested for you, that there are
different conditions which trigger reject_unknown_client_hostname.
Mine was lack of PTR, which also triggers the less aggressive
reject_unknown_reverse_client_hostname restriction. This is fairly
common, and IMO, a pretty likely spam sign. Given my experience, I
think it is time to use reject_unknown_reverse_client_hostname. At
least you know you're not alone in enforcing that policy.

Another condition is when there is a PTR, but the name given does not
resolve. This, too, is not unusual. But IMO it's probably less likely
a spam sign. You might block a few sites where the understanding of
DNS and mail issues is not so strong.

A third condition is when the PTR name resolves to a different IP
address. This is arguably the "worst" case, because it could mean
that a spammer or scammer/spammer is trying to spoof a legitimate
domain. IRL this is not usually the case; more likely just another
poorly managed site.

Most spam is going to come from malware-infected Windows machines or
other compromised hosts being used as a zombie. There are many useful
strategies in dealing with those, including Spamhaus Zen and
reject_non_fqdn_helo_hostname. reject_unknown_reverse_client_hostname
is also very effective, as I think some ISPs might deliberately not
provide reverse DNS for their dynamic ranges.

Most of the rest of it is going to come from large "snowshoe" ranges.
These networks will typically have perfect FCrDNS for every IP
address.

> It appears to be the third case here, that the name->address mapping
> does not match the client IP address. Could this be from a legitimate
> cause, or typically intentionally to be evasive?
>
> Could it be found in a legitimate dynamic environment, such as at an ISP?
>
> Is there a way to log these specific failures so I can get a better
> idea of under what circumstances they occur in my environment?
>
> I'm currently rejecting the following, in this order:
>
>         reject_non_fqdn_sender,

Reasonable, not going to block much; not likely to block any spam,
but the mail it blocks is mail you should not accept anyway.

>         reject_non_fqdn_recipient,

Harmless but useless.

>         reject_unknown_sender_domain,

ditto reject_non_fqdn_sender

>         reject_unknown_recipient_domain,

Harmless but useless. Who is giving you invalid recipients at this
point?

>         reject_unauth_pipelining,

Might catch some zombies.

>         reject_invalid_hostname,

Old syntax, ditto reject_non_fqdn_sender except might also catch a
zombie here and there.

>         reject_non_fqdn_hostname,

Old syntax, very effective against zombies, safe and reasonable.

>         reject_unauth_destination,

(Necessary, no comment needed.)

>         reject_maps_rbl,

Old syntax, could be good or could be disastrous. Switch to the "new"
syntax (new since Postfix 2.0 IIRC) of "reject_rbl_client zone.name".
At this point I'm only using zen.spamhaus.org, but I might be adding
spameatingmonkey. Most important advice regarding DNSBLs is to be
familiar with their policies and aware of their status. Given the
dominance of ancient syntax in your restrictions, I wouldn't be
surprised to see some dead lists among your maps_rbl_domains. :)
--
    Offlist mail to this address is discarded unless
    "/dev/rob0" or "not-spam" is in Subject: header
Reply | Threaded
Open this post in threaded view
|

Re: Unknown senders and spam

Alex Regan
Hi,

> reject_unknown_client_hostname :
>> Is it common practice to have that restriction in a production
>> environment?

[...]

> Note, from the documentation suggested for you, that there are
> different conditions which trigger reject_unknown_client_hostname.
> Mine was lack of PTR, which also triggers the less aggressive
> reject_unknown_reverse_client_hostname restriction. This is fairly
> common, and IMO, a pretty likely spam sign. Given my experience, I
> think it is time to use reject_unknown_reverse_client_hostname. At
> least you know you're not alone in enforcing that policy.

In this thread from just last June, the consensus was that it still
rejected too much mail:

http://www.mail-archive.com/postfix-users@.../msg12683.html

It was only from a few users, but wonder what their experience is
almost a year later.

In any case, I can't even test it, because apparently my postfix
doesn't even understand "warn_if_reject". It silently ignored it, and
silently stopped accepting mail until I realized there were two
hundred messages in the queue after five minutes on a Sunday :-) Most
of it was spam anyway :-)

> Most spam is going to come from malware-infected Windows machines or
> other compromised hosts being used as a zombie. There are many useful
> strategies in dealing with those, including Spamhaus Zen and
> reject_non_fqdn_helo_hostname. reject_unknown_reverse_client_hostname
> is also very effective, as I think some ISPs might deliberately not
> provide reverse DNS for their dynamic ranges.
>
> Most of the rest of it is going to come from large "snowshoe" ranges.
> These networks will typically have perfect FCrDNS for every IP
> address.

....and you're saying the reject_unknown_reverse_client_hostname
wouldn't help here, if I understand correctly?

>>         reject_maps_rbl,
>
> Old syntax, could be good or could be disastrous. Switch to the "new"
> syntax (new since Postfix 2.0 IIRC) of "reject_rbl_client zone.name".

Do you have any (postfix v2) restrictions that we haven't yet seen
here that would be worth sharing for this topic?

> At this point I'm only using zen.spamhaus.org, but I might be adding
> spameatingmonkey. Most important advice regarding DNSBLs is to be

I'm also using just those, and also considering
bb.barracudanetworks.org to reject at SMTP time. How do you think it
compares?

> familiar with their policies and aware of their status. Given the
> dominance of ancient syntax in your restrictions, I wouldn't be
> surprised to see some dead lists among your maps_rbl_domains. :)

I'm somewhat familiar with those, but do you know of a location that
describes the policies of the top five URI and DNS blocklists in one
place? That would sure be useful.

Thanks again for helping me to understand. Certainly upgrading is a
top priority.

Best regards,
Alex
Reply | Threaded
Open this post in threaded view
|

Re: Unknown senders and spam

Noel Jones-2
In reply to this post by /dev/rob0
On 4/18/2010 9:56 PM, /dev/rob0 wrote:
>
>>          reject_unauth_pipelining,
>
> Might catch some zombies.

Note that with older postfix (postfix < 2.6 IIRC)
reject_unauth_pipelining must be used in
smtpd_data_restrictions to be effective.  It won't break
anything in smtpd_recipient_restrictions, but it won't block
anything either.


>
>>          reject_maps_rbl,
>
> Old syntax, could be good or could be disastrous. Switch to the "new"
> syntax (new since Postfix 2.0 IIRC) of "reject_rbl_client zone.name".

Using the old syntax is harmless[1] and still works; the new
syntax was introduced for more flexibility.

[1] harmless until some undefined point in the future when
it's removed and no longer recognized.

   -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: Unknown senders and spam

Noel Jones-2
In reply to this post by Alex Regan
On 4/18/2010 10:24 PM, Alex wrote:

>> Note, from the documentation suggested for you, that there are
>> different conditions which trigger reject_unknown_client_hostname.
>> Mine was lack of PTR, which also triggers the less aggressive
>> reject_unknown_reverse_client_hostname restriction. This is fairly
>> common, and IMO, a pretty likely spam sign. Given my experience, I
>> think it is time to use reject_unknown_reverse_client_hostname. At
>> least you know you're not alone in enforcing that policy.
>
> In this thread from just last June, the consensus was that it still
> rejected too much mail:
>
> http://www.mail-archive.com/postfix-users@.../msg12683.html
>
> It was only from a few users, but wonder what their experience is
> almost a year later.

Yes, reject_unknown_client_hostname is still too strict for
us.  And we're very strict!

But the cool thing about local email policy is that you get to
decide for yourself what's too strict.  Some people do use
reject_unknown_client_hostname, but my impression it that they
are mostly home/hobbyist/very small business.

Rule of thumb:  the more people you have to answer to, the
less strict you must be.

>
> In any case, I can't even test it, because apparently my postfix
> doesn't even understand "warn_if_reject". It silently ignored it, and
> silently stopped accepting mail until I realized there were two
> hundred messages in the queue after five minutes on a Sunday :-) Most
> of it was spam anyway :-)

The "warn_if_reject" feature predates
"reject_unauth_pipelining", which you seem to be using
successfully.  I strongly suspect there was some other error
-- probably a simple typo in your config -- that kept
warn_if_reject from working for you.

 From the (ancient) HISTORY file:

20011105
...
         Feature: put "warn_if_reject" before an smtpd
restriction,
         and that restriction logs warnings without rejecting
mail.

[...]

20020905

         Feature: "smtpd_data_restrictions =
reject_unauth_pipelining"
         blocks mail from SMTP clients that send message content
         before Postfix has replied to the DATA command.  File:



  -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: Unknown senders and spam

Alex Regan
In reply to this post by Noel Jones-2
Hi,

> Note that with older postfix (postfix < 2.6 IIRC) reject_unauth_pipelining
> must be used in smtpd_data_restrictions to be effective.  It won't break
> anything in smtpd_recipient_restrictions, but it won't block anything
> either.

Ah, great. I've moved it and it appears to be working (at least not
complaining).

>> Old syntax, could be good or could be disastrous. Switch to the "new"
>> syntax (new since Postfix 2.0 IIRC) of "reject_rbl_client zone.name".
>
> Using the old syntax is harmless[1] and still works; the new syntax was
> introduced for more flexibility.

Will reject_rhsbl_sender and reject_rhsbl_client work in old versions?

Thanks for being helpful and tolerant when I should be flamed for
using such an old version.

Thanks,
Alex
Reply | Threaded
Open this post in threaded view
|

Re: Unknown senders and spam

Alex Regan
In reply to this post by Noel Jones-2
Hi,

>> http://www.mail-archive.com/postfix-users@.../msg12683.html
>>
>> It was only from a few users, but wonder what their experience is
>> almost a year later.
>
> Yes, reject_unknown_client_hostname is still too strict for us.  And we're
> very strict!

Good to know. I also don't think I can easily make such a change in my
environment.

> The "warn_if_reject" feature predates "reject_unauth_pipelining", which you
> seem to be using successfully.  I strongly suspect there was some other
> error -- probably a simple typo in your config -- that kept warn_if_reject
> from working for you.

I'm trying to do:

    warn_if_reject =  reject_rbl_client backscatter.spameatingmonkey.net

But it appears that's only available in later versions, so I've tried
this, and it also doesn't work:

    warn_if_reject = reject_maps_rbl backscatter.spameatingmonkey.net

> 20020905
>
>        Feature: "smtpd_data_restrictions = reject_unauth_pipelining"

It looks like I have a big project ahead of me to upgrade. What kind
of process is involved with going from such an old version to the
current, independent of all the other software?

Thanks,
Alex
Reply | Threaded
Open this post in threaded view
|

Re: Unknown senders and spam

mouss-4
In reply to this post by Alex Regan
Alex a écrit :

> Hi,
>
>>> Is it common practice to have that restriction in a production environment?
>>>
>>> It appears to be the third case here, that the name->address mapping
>>> does not match the client IP address. Could this be from a legitimate
>>> cause, or typically intentionally to be evasive?
>>>
>> since they put their domain name in their HELO (zaphod.chipchaps.com),
>> they're not trying to evade anything.
>
> Yes, I guess they would have been rejected as a result of my helo checks.
>
>> you could try
>>
>>        check_client_access hash:/etc/postfix/access_unknown
>>
>>
>> smtpd_restriction_classes =
>>        ...
>>        policy_strong
>>
>> policy_strong =
>>        reject_rbl_client bb.barracudacentral.org
>
> Is it possible to use maps_rbl_domains instead of reject_rbl_client
> here?

with maps_rbl_domains, you can't specify which list to check in
different places. since you're already using it in the "general" case,
if you add barracuda list, it will apply unconditionally, which is
different from my suggestion to call it when the clien is unknown.

but if you think barracuda list is safe for you (it's not for me. the
corresponding score in spamassassin confirms this for me), you can use it.

> It appears this machine has a version of postfix that doesn't
> understand reject_rbl_client.
>
> Thanks again!
> Best regards,
> Alex

Reply | Threaded
Open this post in threaded view
|

Re: Unknown senders and spam

Bill Weiss-5
In reply to this post by Alex Regan
Alex([hidden email])@Mon, Apr 19, 2010 at 01:11:01AM -0400:

> Hi,
>
> >> http://www.mail-archive.com/postfix-users@.../msg12683.html
> >>
> >> It was only from a few users, but wonder what their experience is
> >> almost a year later.
> >
> > Yes, reject_unknown_client_hostname is still too strict for us.  And we're
> > very strict!
>
> Good to know. I also don't think I can easily make such a change in my
> environment.
>
> > The "warn_if_reject" feature predates "reject_unauth_pipelining", which you
> > seem to be using successfully.  I strongly suspect there was some other
> > error -- probably a simple typo in your config -- that kept warn_if_reject
> > from working for you.
>
> I'm trying to do:
>
>     warn_if_reject =  reject_rbl_client backscatter.spameatingmonkey.net
>
> But it appears that's only available in later versions, so I've tried
> this, and it also doesn't work:
>
>     warn_if_reject = reject_maps_rbl backscatter.spameatingmonkey.net

You probably want:
    warn_if_reject reject_maps_rbl backscatter.spameatingmonkey.net
without the "=".

--
Bill Weiss
 
We will not prove this by intimidation and excessive fist waving.
[while screaming these lines and frantically waving arms]
    -- Dr. Max Mintx, Math. Foundations of CS
        University of Pennsylvania

Reply | Threaded
Open this post in threaded view
|

Re: Unknown senders and spam

mouss-4
In reply to this post by Alex Regan
Alex a écrit :

> Hi,
>
>>> http://www.mail-archive.com/postfix-users@.../msg12683.html
>>>
>>> It was only from a few users, but wonder what their experience is
>>> almost a year later.
>> Yes, reject_unknown_client_hostname is still too strict for us.  And we're
>> very strict!
>
> Good to know. I also don't think I can easily make such a change in my
> environment.
>
>> The "warn_if_reject" feature predates "reject_unauth_pipelining", which you
>> seem to be using successfully.  I strongly suspect there was some other
>> error -- probably a simple typo in your config -- that kept warn_if_reject
>> from working for you.
>
> I'm trying to do:
>
>     warn_if_reject =  reject_rbl_client backscatter.spameatingmonkey.net
>

wrong syntax. it's
        warn_if_reject reject_rbl_client $yourlist
There's no 'equal' sign.

> But it appears that's only available in later versions, so I've tried
> this, and it also doesn't work:
>
>     warn_if_reject = reject_maps_rbl backscatter.spameatingmonkey.net
>

doubly wrong syntax. besides the '=' sign, reject_rbl_maps doesn't take
an argument.

>> 20020905
>>
>>        Feature: "smtpd_data_restrictions = reject_unauth_pipelining"
>
> It looks like I have a big project ahead of me to upgrade. What kind
> of process is involved with going from such an old version to the
> current, independent of all the other software?
>
> Thanks,
> Alex

Reply | Threaded
Open this post in threaded view
|

Re: Unknown senders and spam

Alex Regan
Hi,

>> I'm trying to do:
>>
>>     warn_if_reject =  reject_rbl_client backscatter.spameatingmonkey.net
>>
>
> wrong syntax. it's
>        warn_if_reject reject_rbl_client $yourlist
> There's no 'equal' sign.

$ postfix check
postfix: fatal: /etc/postfix/main.cf, line 700: missing '=' after
attribute name: "warn_if_reject reject_maps_rbl
backscatter.spameatingmonkey.net"
Apr 19 02:35:33 smtp01 postfix[13351]: fatal: /etc/postfix/main.cf,
line 700: missing '=' after attribute name: "warn_if_reject
reject_maps_rbl backscatter.spameatingmonkey.net"

>> But it appears that's only available in later versions, so I've tried
>> this, and it also doesn't work:
>>
>>     warn_if_reject = reject_maps_rbl backscatter.spameatingmonkey.net
>
> doubly wrong syntax. besides the '=' sign, reject_rbl_maps doesn't take
> an argument.

Looks like I'm SOL for now?  :-)

Thanks again,
Alex
Reply | Threaded
Open this post in threaded view
|

Re: Unknown senders and spam

Stan Hoeppner
In reply to this post by Noel Jones-2
Noel Jones put forth on 4/18/2010 10:55 PM:

> Yes, reject_unknown_client_hostname is still too strict for us.  And
> we're very strict!

I ran with this for a short while.  Had problems with it rejecting Hotmail
connections.  And these weren't Hotmail user mails beings delivered, but
responses to my spam reports coming from the Hotmail abuse dept.  Had too
many other legit mails refused as well.  It didn't stop any more spam here
than reject_unknown_reverse_client_hostname so I reverted back to the latter.

--
Stan
12