|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: MacShane, Tracy (Tracy.Macshane
AirservicesAustralia.com)
Date: Wed Oct 10 2007 - 19:15:50 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> -----Original Message-----
> From: owner-postfix-users
postfix.org
> [mailto:owner-postfix-users
postfix.org] On Behalf Of Noel Jones
> Sent: Thursday, 11 October 2007 12:35 AM
> To: postfix-users
postfix.org
> Subject: Re: Address verification issues
>
> At 02:20 AM 10/10/2007, MacShane, Tracy wrote:
> >Unfortunately, while checking everything else at each, I neglected to
> >check address verification, which we have set up for a couple of
> >domains (gmail.com being the most notable), per the instructions at
> >Postfix.org.
> >
> >The whole point of implementing the address verification was to allow
> >certain domains which don't spam us (yet) to bypass the RBL - perhaps
> >I'm barking up the wrong tree by assuming that the address
verification
> >effectively gives an OK at the end of the process,
>
>
> reject_unverified_{sender, recipient} can only return DUNNO
> or REJECT, never OK. As such, this cannot be used as a
> whitelisting tool.
Ah, ok, I was thinking (from this issue) that that might be the case. Oh
well.
>
> You could use a restriction class with
> reject_unverified_sender
> permit
> as the defined actions.
I think I might give this a go.
>
> But probably better to use a check_client_access whitelist
> and forget about sender verification.
Yes, I've certainly done that with other domains, but I really am
reluctant to do that to all of Google. If they had a nice convenient
list of all their mail relay servers somewhere, that would be handy.
I'll see if I can figure out some kind of algorithm they use for naming
their mail servers (or if they use a narrow range of networks to send
from, but it doesn't seem that way so far).
> >smtpd_recipient_restrictions =
> > reject_non_fqdn_recipient,
> > reject_unknown_recipient_domain,
> > permit_mynetworks,
> > reject_unauth_pipelining,
>
> reject_unauth_pipelining is not effective here, put it under
smtpd_data_restrictions instead.
Oops, will do.
>
> > reject_multi_recipient_bounce
>
> This doesn't reject much in the way of spam, but may reject
> legit mail. Its value is questionable...
I'll look into that one, then. I have a feeling it was rejecting some
spammy stuff at some stage, but if it's not actively doing anything at
present, I'll remove it.
>
> > reject_non_fqdn_sender,
> > reject_unauth_destination,
>
> This is a good place (ie. just after
> reject_unauth_destination) for a whitelist.
> check_client_access hash:/etc/postfix/client_whitelist
>
> > reject_invalid_hostname,
> > check_sender_access hash:/etc/postfix/sender_access,
> > check_helo_access hash:/etc/postfix/helo_access,
> > reject_non_fqdn_hostname,
> > check_client_access cidr:/etc/postfix/cidr_client_access,
> > check_client_access hash:/etc/postfix/client_access,
> > reject_unknown_hostname,
>
> the above is likely to reject legit mail.
>
> > check_sender_access hash:/etc/postfix/sender_bypass,
>
> It's generally better to whitelist clients rather than sender
> domains, since senders are easily and frequently forged.
Yes, but most of these are for domains like Google (or Optus here in
Oz), which regularly have hosts appear on the RBL at random, and which
seem to have dozens (if not hundreds) of relay servers. When a user
wants their mail immediately, and 6 different messages get relayed by 6
different servers on 6 different networks within the space of a day, it
makes it a bit tricky. Sure, I can whitelist each host as it gets
blocked, but that's fairly laborious. I really wish that certain ISPs
would reserve a namespace or network(s) for their relay servers so that
us poor people at the other end can identify where mail is likely to
originate from. < /grumble>
>
> > reject_unknown_sender_domain,
> > check_recipient_access pcre:/etc/postfix/recipient_access,
> ># check_client_access pcre:/etc/postfix/tpg_map,
> > reject_rbl_client ASP...r.mail-abuse.com,
> > reject_rbl_client ASP...q.mail-abuse.com # check_sender_access
> >hash:/etc/postfix/spf_bypass # check_policy_service
> >unix:private/policy,
>
> Postfix doesn't allow in-line comments or the
> reject_rbl_client syntax as shown above - I hope this is just
> your way of annotating your list posting and not actually in
> your main.cf.
No, sorry, that was bad cutty-pasty.
Thanks for the illumination; back to the drawing board!
>
> --
> Noel Jones
>
>
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]