 |
| Prev-20 | Home | Next-20 |
| Prev-20 | Home | Next-20 |
| Prev-Msg | Prev-Thread | Postfix-users | Jan-2008 | Next-Thread | Next-Msg |
| Subject: | Re: Question on Earthlink and dnsbl.sorbs.net |
| Group: | Postfix-users |
| From: | mouss |
| Date: | 15 Jan 2008 |
> I know you guys hate these newbie questions, but I have a hard time keeping up
> with the latest in postfix. :)
>
> Basically dnsbl.sorbs.net has been intermittently rejecting messages from
> earthlink. net. I got an email thru them Friday but yesterday it began
> blocking their emails again.
>
> Now I don't know anything about the history here. Is dnsbl.sorbs.net known for
> too much blocking? Should I use someone else? Or is earthlink a known spam
> source?
>
sorbs do not whitelist ISPs. If they receive (some amount of) spam from
ISPs, they list them. There is no "they are too big to block". Whether
this is ok for you or not is up to you.
Please read sorbs policy and documents and subscribe to sorbs mailing
lists. discussion of sorbs policy is not appropriate on a postfix list.
> What would be the recommended next step here? Should I use another spam
> blocker? Or is there a way in postfix to just let her messages get thru?
>
if you want to receive mail from ISPs that may be blocked by sorbs, you
have two choices:
- disable sorbs (or use a safe sublist of sorbs).
- use a whitelist. The latter obviously requires work to maintain the
whitelist
> This is the log message:
>
> mail.info:Jan 15 09:30:32 venture postfix/smtpd[9039]: NOQUEUE: reject: RCPT
> from smtpauth15.mail.atl.earthlink.net[209.86.89.75]: 554 5.7.1 Service
> unavailable; Client host [209.86.89.75] blocked using dnsbl.sorbs.net;
> Currently Sending Spam See: http://www.sorbs.net/lookup.shtml?209.86.89.75;
> from=<her> to=<me> proto=SMTP
> helo=<smtpauth15.mail.atl.earthlink.net>
>
> And here's the applicable portion of my main.cf:
>
> defer_transports =
> disable_dns_lookups = no
> strict_8bitmime = no
> disable_mime_output_conversion = no
> smtpd_sender_restrictions = hash:/etc/postfix/access,reject_unknown_address
> smtpd_helo_required = yes
> strict_rfc821_envelopes = no
> smtpd_data_restrictions = reject_unauth_pipelining
> smtpd_recipient_restrictions =
> reject_non_fqdn_sender
> reject_non_fqdn_recipient
> reject_unknown_sender_domain
> reject_unknown_recipient_domain
If this server is used for mail submission by MUAs, then this is not
very nice to your users (a MUA does not queue mail and resubmit it
automatically, so a DNS failure will irritate your users).
you'd better remove reject_unknown_recipient_domain, and move
reject_unknown_sender_domain to after reject_unaauth_destination (which
will save you a DNS query in the case of relay attempts).
> permit_mynetworks
> reject_unauth_destination
> reject_unauth_pipelining
this is useless here. there is no unauth_pipelining at rcpt stage.
> reject_invalid_hostname
> reject_rbl_client bl.spamcop.net
> reject_rbl_client list.dsbl.org
> reject_rbl_client zen.spamhaus.org
> reject_rbl_client dnsbl.sorbs.net
> permit
> smtp_sasl_auth_enable = no
> smtpd_sasl_auth_enable = no
> smtpd_use_tls = no
> smtp_use_tls = no
> alias_maps = hash:/etc/aliases
> mailbox_size_limit = 0
> message_size_limit = 10240000
> myorigin = $mydomain
> relay_domains = $mynetworks
> smtpd_client_restrictions = permit_mynetworks, reject_rbl_client
> zen.spamhaus.org, permit
you are repeating spamhaus check. remove smtpd_client_restrictions at once.
>
> Thanks!
>
> Doug
>
>
>
| Prev-Msg | Prev-Thread | Postfix-users | Jan-2008 | Next-Thread | Next-Msg |