Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Robert Moskowitz (rgmhtt-consult.com)
Date: Thu Dec 09 2010 - 20:43:02 CST
On 12/09/2010 10:31 AM, mouss wrote:
> Le 09/12/2010 14:54, Robert Moskowitz a écrit :
>> This is a new install on Fedora 12 using the tools from:
>> We have patched the Postfix source to add the Quota patch. It would be
>> REALLY nice if this was just a part of Postfix
> The VDA is patch is not supported. it doesn't look like there's
> anything new that would cause change...
I assumed it was not supported, or it would not still be a patch. Why
is it likely to be supported? It seems quotas are common, is there a
>> that came disabled
> it came disabled in your package. it doesn't come at all from postfix
I was not clear; perhaps my dyslexia. What I mean it would be nice if
this bit of code were rolled into the postfix program with a parameter
that controlled its activity. Normally off but with one config change
it would be available to those that want it.
>> was 'easy' to enable so we could work from the standard rpms.
> but then don't ask for support here. if you have a problem related to
> unsupported patches, you'll have to ask the patch author...
Just would like to work from distributed rpm instead of compiling
patched source. I just kind of spoiled that way.
>> The system is using Postfix with a mySQL tables along with lots of
>> The main domain supported has multiple MX records, as over the years I
>> have been without power for more than 24 hours.
> so? I have voluntarily stopped my MX for longer than that! if the
> client doesn't follow the common 4/5 days de facto standard, then it's
> a client problem.
Perhaps goes back to when I brought my domain up in '95 over a dialup
link and how mailing lists would drop me if I was not around for a few
hours. I got paranoid about it, and relays were 'common' back then in
the good old days. I have been thinking about dropping them and this
has pushed me to try it.
>> SO my ISP acts as a
>> relay service for me. I am aware that this means that I send bunches of
>> bounces for emails to unkown users. I have NOT figured out what I am
>> going to do about this.
> if your ISP doesn't validate recipient addresses in your domain,
> please disable this relay. otherwise, you're part of the problem and
> you should be blacklisted (based on domain, sender, IP, and any
> information related to you). that means black tainting: 22.214.171.124
> and htt-consult.com.
I do need to talk to my ISP about this some more about ways for them to
check my valid users. See if they are interested in doing the 'extra'
work. Meanwhile, I have done what I have been thinking about doing
since I figured this out a little while back and dropped the relays as
MX records. Give it a bit of time for it to propagate around the net
and I will see what the stats are reported in Logwatch.
And oh by the way, that is the IP address of my notebook where I send
this email from. Not the IP addr of my mail server.
>> I can't tell if I am relaying stuff I should be killing instead. Maybe
>> it is the above bounces I am seeing. At the end I have included my
>> postconf -n output.
>> DCC looks like is is just not working. LOTS of failures to connect. What
>> port does it use? Perhaps I am blocking it.
> sooorry. I don't use DCC. anyway this is off topic here.
But perhaps someone else here does use it...
>> Thank you for any and all help provided.
>> -------- Original Message --------
> [snip] irrelevant and off topic logwatch removed.
>> ###################### Logwatch End #########################
>> postconf -n
>> alias_database = hash:/etc/aliases
>> alias_maps = hash:/etc/aliases, hash:/etc/mailman/aliases
>> broken_sasl_auth_clients = yes
>> command_directory = /usr/sbin
>> config_directory = /etc/postfix
>> content_filter = amavis:[127.0.0.1]:10024
>> daemon_directory = /usr/libexec/postfix
>> data_directory = /var/lib/postfix
>> debug_peer_level = 2
>> html_directory = no
>> inet_interfaces = all
> this the default. just remove the setting from your main.cf.
I need eth0 and loopback. These are the only interfaces on the box.
What is the difference between all or eth0, lo ?
>> inet_protocols = all
>> mail_owner = postfix
>> mailq_path = /usr/bin/mailq.postfix
>> manpage_directory = /usr/share/man
>> mydestination = klovia.htt-consult.com, localhost, localhost.localdomain
>> myhostname = klovia.htt-consult.com
>> mynetworks = 127.0.0.0/8
> you don't have mydomain nor myorigin. the default values will apply.
> if the defaults are ok, then it's ok. otherwise, specify explicitely.
My understanding is that the domain SQL table replaces this?
>> newaliases_path = /usr/bin/newaliases.postfix
>> proxy_read_maps = $local_recipient_maps $mydestination
>> $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $vi
>> rtual_mailbox_domains $relay_recipient_maps $relay_domains
>> $canonical_maps $sender_canonical_maps $recipient_canonical_maps
>> $relocated_maps $transport_maps $mynetworks $virtual_mailbox_limit_maps
>> queue_directory = /var/spool/postfix
>> readme_directory = /usr/share/doc/postfix-2.6.5/README_FILES
>> receive_override_options = no_address_mappings
>> recipient_delimiter = +
> you don't have relay_domains. check the default. if you don't need
> relay_domain. specify
> relay_domains =
According to: http://www.postfix.org/postconf.5.html
"allow_untrusted_routing (default: no)
Forward mail with sender-specified routing
(user[%!]remote[%!]site) from untrusted clients to destinations
By default, this feature is turned off. This closes a nasty open
relay loophole where a backup MX host can be tricked into forwarding
junk mail to a primary MX host which then spams it out to the world. "
>> sample_directory = /usr/share/doc/postfix-2.6.5/samples
>> sendmail_path = /usr/sbin/sendmail.postfix
>> setgid_group = postdrop
>> smtpd_recipient_restrictions = permit_mynetworks,
>> permit_sasl_authenticated, reject_unauth_destination
> you might need some anti-spam checks, such as
> reject_rbl_client zen.spamhaus.org
I am running quite a bit of spam checking. Spamassassin along with
amavisd and clamav.
Razor, Pyzor and DCC are the spamfilters in use.
But DCC gives me all those connection errors, I need to find out what
port it is using and if I have it blocked at my firewall.