Re: Tracking down a mail forwarding loop
LuKreme wrote: I have a local user who is generating occasional mail forwarding loop errors, which are causing forged emails to cause NDNs and fill up mailq. Jan 30 13:46:08 mail postfix/local[44147]: 7020950D4D4: to=*bob*@covisp.net, relay=local, delay=0.65, delays=0.59/0/0/0.06, dsn=5.4.6, status=bounced (mail forwarding loop for *bob*@covisp.net) The only place that “*bob*” is mentioned in virtual is in line like this: bill...@covisp.net bob,fred,george Where bob, fred, and george are all local users. bob doesn’t have a .forward, and I looked at his .procmailrc and it’s not forwarding mail anywhere. Where else do I look? postmap -q b...@covisp.net /etc/postfix/virtual doesn’t return any results. I'd start with the headers in a message that's looped - that might help track things down. Miles Fidelman
Re: TUNING_README: persistent write cache?
So it's hardware and not the Unix cache/buffers that keep things in RAM to improve performance. Thank you for clarifying! On Wed, Feb 4, 2015 at 3:59 PM, Wietse Venema wie...@porcupine.org wrote: Andrew Bourgeois: But what does persistent write cache mean? What needs to be changed on the OS level? Google doesn't clearly link persistent write cache to a Linux feature. It is a hardware feature found in RAID controllers and in server I/O accelerators. The basic idea is to serialize random writes. SSHD disks may provide similar improvements with random I/O. Wietse
Re: TLS verification woes
Hi Viktor Dukhovni wrote on 03.02.2015 18:12: On Tue, Feb 03, 2015 at 04:41:40PM +, Viktor Dukhovni wrote: If your Postfix is old enough, and is linked against OpenSSL 0.9.8, it only supports md5 and sha1. Thanks, Viktor, that'll be it. Old enough means older than these: [...] Date: Thu Sep 5 08:55:00 2013 -0400 postfix-2.8.16 It's postfix-2.8.5 or, to be more precise, postfix-2.8.5-2~build0.10.04, and, as you assume, linked OpenSSL 0.9.8. I guess I'll have to relax the TLS policy for this domain until we can upgrade the system. Thanks for the swift and accurate analysis! Cheers, Tobias
PATCH: PIE for Postfix 3.1
Wietse Venema: Indeed. PIE support is a new feature. New features are not added during the code freeze. You're welcome to back-port this new feature once we have tested it in Postfix 3.1 with multiple build options (shared/nonshared) and with multiple OS distributions. This does not appear to require tests on multiple hardware architectures. Very lighty-tested patch follows. No INSTALL documentation until this has been tested. Usage: $ make makefiles pie=yes ... Wietse diff -ur /var/tmp/postfix-3.1-20150201/makedefs ./makedefs --- /var/tmp/postfix-3.1-20150201/makedefs 2015-01-31 19:06:20.0 -0500 +++ ./makedefs 2015-02-04 12:50:05.0 -0500 @@ -105,6 +105,13 @@ # dynamicmaps=yes implicitly enables Postfix shared libraries. # # This feature was introduced with Postfix 3.0. +# .IP \fBpie=yes\fR +# .IP \fBpie=no\fR +# +# Enable (disable) Postfix builds with position-independent +# executables, on platforms where this is supported. +# +# This feature was introduced with Postfix 3.1. # .IP \fIinstallation_parameter\fB=\fIvalue\fR... # Override the compiled-in default value of the specified # installation parameter(s). The following parameters are @@ -142,6 +149,7 @@ echo # AUXLIBS=$AUXLIBS env | grep '^AUXLIBS_' | sed 's/^/# /' echo # dynamicmaps=$dynamicmaps +echo # pie=$pie # Defaults for most sane systems @@ -1082,6 +1090,19 @@ '` esac +# Choose between PIE and non-PIE builds. + +case $pie in + yes) case $CCARGS in +* -fPIC *) ;; + *) CCARGS_PIE=-fPIC;; + esac + SYSLIBS_PIE=-pie;; +|no) ;; +*) error Specify \pie=yes\ or \pie=no\;; +esac + + # Finally... sed 's/ */ /g' EOF @@ -1090,8 +,8 @@ _AR= $_AR ARFL = $ARFL _RANLIB= $_RANLIB -SYSLIBS= $AUXLIBS $SYSLIBS $PLUGIN_AUXLIBS -CC = $CC $CCARGS \$(WARN) +SYSLIBS= $SYSLIBS_PIE $AUXLIBS $SYSLIBS $PLUGIN_AUXLIBS +CC = $CC $CCARGS_PIE $CCARGS \$(WARN) OPT= $OPT DEBUG = $DEBUG AWK= $AWK
Working around recalcitrant ISP wrt rDNS
I have been 'working' with my new ISP for a couple weeks to get the rDNS setup for my server move (I am changing ISPs for a number of reasons). I was assured on signing that setting up rDNS was 'easy'; it is not. DIGing up the SOA on my IP rDNS tends to indicate that they have not updated that zone for many months. Anyway,,, A friend using the same ISP 'solved' this by changing his SMTP server to say the mail for his domain is ok to come from the ISP PTR value. So let's say that: My server is: z9m9z.htt-consult.com And further assume that the reverse for the address where I want to move it to has a PTR of 9.254.253.50.in-addr.arpa. 3600INPTR 50-253-254-9-static.hfc.comcastbusiness.net. And that 50-253-254-9-static.hfc.comcastbusiness.net has no RR (e.g. A or CNAME). Is there someway to get postfix to provide the needed inforation to the recipient MTA that this is OK and valid? I am asking, but I suspect that even if I send out things OK, there will be MTAs out there that will not let their clients send mail to me as my rDNS does not match. I am pushing the ISP that will remain unnamed. (oops. :) ) I was told that 'they are working on it'. Meanwhile I am paying double as I cannot migrate my server. I will be pleased if there is a real workaround, but not overly disappointed if the only way out is through.
Adding multiple headers
The PREPEND action can add a single header to outgoing mail. Is there a way to add multiple headers? ...don support (at) microtechniques.com
Re: Adding multiple headers
I tried that, but it only triggered on the first one. On 4 Feb 2015 at 14:52, Noel Jones wrote: On 2/4/2015 2:09 PM, System Support wrote: The PREPEND action can add a single header to outgoing mail. Is there a way to add multiple headers? ...don support (at) microtechniques.com Use the PREPEND action multiple times. -- Noel Jones ...don support (at) microtechniques.com
Re: Working around recalcitrant ISP wrt rDNS
Am 04.02.2015 um 22:54 schrieb Noel Jones:
On 2/4/2015 3:12 PM, li...@rhsoft.net wrote:
*sadly* that sort of incoming rules is not widespreaded enough,
otherwise spam from infected botnet zombies would no longer exist
and frankly the rule for IPhfc.comcastbusiness.net is manually
written by look at the incoming junk amount all day long hitting the
contentfilter and no single legit mail without SPF/DNSWL over months
/^[\.\-]?([0-9]{1,3}[\.\-]){2,4}[\.\-]?[a-z]{4,20}[\.\-]hfc[\.\-]comcastbusiness[\.\-](co|com|net|org)$/
REJECT Generic DNS-Reverse-Lookup (PTR-Rule: 435) see
http://www.emailtalk.org/ptr.aspx or configure
http://en.wikipedia.org/wiki/Sender_Policy_Framework
even if it is not a directly reject *every* SpamAssassin setup on
this planet gives you a penalty for such a PTR and that maybe the
last piece needed for a milter-reject - in that case you don't know
the reasons, with the reject above you do
score RDNS_DYNAMIC 2.639 0.363 1.663 0.982
score NO_RDNS_DOTCOM_HELO 3.100 0.433 3.099 0.823
Your filter is broken if it can't tell the difference between a
static and dynamic PTR.
your mailsetup is broken if you don't care about basics like a sane PTR
and frankly even the admin before me not cared about much things
insisted more than 10 years ago the we never ever send out mails from a
generic PTR
the truth is that a xx.xx.xx.xx-static-dsl.isp.tld is not a mailserver
just becaus eit contains the word static - in fact most of them are
ordinary office dsl lines with clients behind
There are a lot of zombies in the *.comcastbusiness.* PTR space, but
you throw out the baby with the bathwater. There are other ways to
get rid of the zombies on static IPs without wholesale blocking.
Greylisting and a couple reliable RBLs (or postscreen) will block
the vast majority of zombies without wholesale slaughter.
you did not get the point:
if PTR's with a IP-part would be rejected worldwide and ISP's would
block outgoing port 25 for homeusers the business of infect client PCs
to send out malware to MX hosts would die from one day to the next
* greylisting does *much* more harm be it for large senders
retry with a dfiierent IP or sender verification on the
other side for your own outgoing mail
* all the dialupo RBLs are far from complete
* other RBLs are way too late, if someone makes it on them
he already had sucess in send his crap out
* there is no single reason for not have a sane PTR
* postfix has even a setting that A/PTR needs to *match*
and if someone enables that we no longer dicuss about
the PTR part in the reverse DNS at all
See, even you don't block everyone with an offending PTR -- you
check for valid SPF or dnswl
because the intention is *not* to block mailservers
a random enduser IP i not listed in the SPF record nor on DNSWL's
Re: Working around recalcitrant ISP wrt rDNS
On 2/4/2015 1:47 PM, Robert Moskowitz wrote: I have been 'working' with my new ISP for a couple weeks to get the rDNS setup for my server move (I am changing ISPs for a number of reasons). I was assured on signing that setting up rDNS was 'easy'; it is not. DIGing up the SOA on my IP rDNS tends to indicate that they have not updated that zone for many months. Anyway,,, A friend using the same ISP 'solved' this by changing his SMTP server to say the mail for his domain is ok to come from the ISP PTR value. So let's say that: My server is: z9m9z.htt-consult.com And further assume that the reverse for the address where I want to move it to has a PTR of 9.254.253.50.in-addr.arpa. 3600INPTR 50-253-254-9-static.hfc.comcastbusiness.net. And that 50-253-254-9-static.hfc.comcastbusiness.net has no RR (e.g. A or CNAME). Is there someway to get postfix to provide the needed inforation to the recipient MTA that this is OK and valid? I am asking, but I suspect that even if I send out things OK, there will be MTAs out there that will not let their clients send mail to me as my rDNS does not match. I am pushing the ISP that will remain unnamed. (oops. :) ) I was told that 'they are working on it'. Meanwhile I am paying double as I cannot migrate my server. I will be pleased if there is a real workaround, but not overly disappointed if the only way out is through. Don't worry about *receiving* mail. Other systems sending you mail don't care a bit about what the name of your MX server is, or what kind of IP it's hosted on, as long as the MX name resolves to the correct IP. Feel free to reuse your current z9m9z.htt-consult.com as an MX name, or use something totally different. There are potential problems with *sending* mail. All the comcast business IPs that I know of already have proper FCrDNS. This is necessary to communicate with sites that use reject_unknown_client_hostname or similar. If your new IP's PTR has no matching A record, get that solved first before you tackle trying to get a custom PTR. This should be an easier problem to fix. Once you have FCrDNS (even with an unwanted PTR name), you should be able to safely move. Do some testing -- just hook some PC up to the new connection and use telnet (or the very handy mini_smtp tool) to send some test mails directly to various servers. Configure postfix with a HELO name (smtp_helo_name) something like z9m9z.htt-consult.com rather than the more technically correct PTR name. Make sure the HELO hostname has an A record pointing to your IP. (bonus points for a name containing smtp, e?mail, mx, mta, etc.) This helps you look more like a mail server and less like a bot. Make sure you have an SPF record including your IP. If you use the same IP for sending and receiving, just include the spf mx key. (looks as if you have that already... good) -- Noel Jones
Re: Working around recalcitrant ISP wrt rDNS
Am 04.02.2015 um 21:51 schrieb Noel Jones:
On 2/4/2015 2:37 PM, li...@rhsoft.net wrote:
it don't matter if it matches - if you are coming with such a PTR
you are rejected - on my setup this is skipped at least if the
envelope domain has a SPF policy listing that IP or if you are on
one of 11 public DNSWL
ptr-check.sh 50-253-254-9-static.hfc.comcastbusiness.net
REJECT Generic DNS-Reverse-Lookup (PTR-Rule: 417) see
http://www.emailtalk.org/ptr.aspx or configure
http://en.wikipedia.org/wiki/Sender_Policy_Framework
Your server, your rules. Thankfully this sort of incoming rule
isn't widespread.
*sadly* that sort of incoming rules is not widespreaded enough,
otherwise spam from infected botnet zombies would no longer exist and
frankly the rule for IPhfc.comcastbusiness.net is manually written
by look at the incoming junk amount all day long hitting the
contentfilter and no single legit mail without SPF/DNSWL over months
/^[\.\-]?([0-9]{1,3}[\.\-]){2,4}[\.\-]?[a-z]{4,20}[\.\-]hfc[\.\-]comcastbusiness[\.\-](co|com|net|org)$/
REJECT Generic DNS-Reverse-Lookup (PTR-Rule: 435) see
http://www.emailtalk.org/ptr.aspx or configure
http://en.wikipedia.org/wiki/Sender_Policy_Framework
even if it is not a directly reject *every* SpamAssassin setup on this
planet gives you a penalty for such a PTR and that maybe the last piece
needed for a milter-reject - in that case you don't know the reasons,
with the reject above you do
score RDNS_DYNAMIC 2.639 0.363 1.663 0.982
score NO_RDNS_DOTCOM_HELO 3.100 0.433 3.099 0.823
if a postmaster is not able to
* care about a PTR not containing an IP
* care about make it on one of the many DNSWL
* setup SPF properly
he don't care about relieable delivery, otherwise he would at least use
a sane relay-host
Which reminds me that the OP should register his domain and IP on
dnswl.org (free and easy)
junkemailfilter.com LISTED 127.0.0.5
exists for our range even without do anything
permit_dnswl_client hostkarma.junkemailfilter.com=127.0.0.[1;3;5]
__
ips.whitelisted.org
list.dnswl.org
wl.mailspike.net
iadb.isipp.com
sa-accredit.habeas.com
dnswl.inps.de
swl.spamhaus.org
junkemailfilter.com
Re: Working around recalcitrant ISP wrt rDNS
On 2/4/2015 3:12 PM, li...@rhsoft.net wrote:
*sadly* that sort of incoming rules is not widespreaded enough,
otherwise spam from infected botnet zombies would no longer exist
and frankly the rule for IPhfc.comcastbusiness.net is manually
written by look at the incoming junk amount all day long hitting the
contentfilter and no single legit mail without SPF/DNSWL over months
/^[\.\-]?([0-9]{1,3}[\.\-]){2,4}[\.\-]?[a-z]{4,20}[\.\-]hfc[\.\-]comcastbusiness[\.\-](co|com|net|org)$/
REJECT Generic DNS-Reverse-Lookup (PTR-Rule: 435) see
http://www.emailtalk.org/ptr.aspx or configure
http://en.wikipedia.org/wiki/Sender_Policy_Framework
even if it is not a directly reject *every* SpamAssassin setup on
this planet gives you a penalty for such a PTR and that maybe the
last piece needed for a milter-reject - in that case you don't know
the reasons, with the reject above you do
score RDNS_DYNAMIC 2.639 0.363 1.663 0.982
score NO_RDNS_DOTCOM_HELO 3.100 0.433 3.099 0.823
Your filter is broken if it can't tell the difference between a
static and dynamic PTR.
There are a lot of zombies in the *.comcastbusiness.* PTR space, but
you throw out the baby with the bathwater. There are other ways to
get rid of the zombies on static IPs without wholesale blocking.
Greylisting and a couple reliable RBLs (or postscreen) will block
the vast majority of zombies without wholesale slaughter.
See, even you don't block everyone with an offending PTR -- you
check for valid SPF or dnswl.
-- Noel Jones
Re: Working around recalcitrant ISP wrt rDNS
On 2/4/2015 2:37 PM, li...@rhsoft.net wrote: it don't matter if it matches - if you are coming with such a PTR you are rejected - on my setup this is skipped at least if the envelope domain has a SPF policy listing that IP or if you are on one of 11 public DNSWL ptr-check.sh 50-253-254-9-static.hfc.comcastbusiness.net REJECT Generic DNS-Reverse-Lookup (PTR-Rule: 417) see http://www.emailtalk.org/ptr.aspx or configure http://en.wikipedia.org/wiki/Sender_Policy_Framework Your server, your rules. Thankfully this sort of incoming rule isn't widespread. Which reminds me that the OP should register his domain and IP on dnswl.org (free and easy). -- Noel Jones
Re: Working around recalcitrant ISP wrt rDNS
On 02/04/2015 03:46 PM, Noel Jones wrote: On 2/4/2015 1:47 PM, Robert Moskowitz wrote: I have been 'working' with my new ISP for a couple weeks to get the rDNS setup for my server move (I am changing ISPs for a number of reasons). I was assured on signing that setting up rDNS was 'easy'; it is not. DIGing up the SOA on my IP rDNS tends to indicate that they have not updated that zone for many months. Anyway,,, A friend using the same ISP 'solved' this by changing his SMTP server to say the mail for his domain is ok to come from the ISP PTR value. So let's say that: My server is: z9m9z.htt-consult.com And further assume that the reverse for the address where I want to move it to has a PTR of 9.254.253.50.in-addr.arpa. 3600INPTR 50-253-254-9-static.hfc.comcastbusiness.net. And that 50-253-254-9-static.hfc.comcastbusiness.net has no RR (e.g. A or CNAME). Is there someway to get postfix to provide the needed inforation to the recipient MTA that this is OK and valid? I am asking, but I suspect that even if I send out things OK, there will be MTAs out there that will not let their clients send mail to me as my rDNS does not match. I am pushing the ISP that will remain unnamed. (oops. :) ) I was told that 'they are working on it'. Meanwhile I am paying double as I cannot migrate my server. I will be pleased if there is a real workaround, but not overly disappointed if the only way out is through. Don't worry about *receiving* mail. Other systems sending you mail don't care a bit about what the name of your MX server is, or what kind of IP it's hosted on, as long as the MX name resolves to the correct IP. Feel free to reuse your current z9m9z.htt-consult.com as an MX name, or use something totally different. There are potential problems with *sending* mail. All the comcast business IPs that I know of already have proper FCrDNS. This is necessary to communicate with sites that use reject_unknown_client_hostname or similar. If they run your domain (at an additional cost), they take care of the rDNS. If not, you have to put a request in that gets bounced around a couple of times until someone figures out what you are asking about. If your new IP's PTR has no matching A record, get that solved first before you tackle trying to get a custom PTR. This should be an easier problem to fix. I will change my A record only after the PTR is created. If I change my A record first by adding it as a second A record, any server that tries it will get a connection failure as I have not moved my system yet. If I change my A record and move the system before the rDNS is done, I am back to that mess I got myself in before with a bad rDNS floating around. The only way I see for a smooth migration of an existing server is: 1) setup rDNS - this hurts no one, as since nothing is on the address, no one is doing an rDNS lookup. 2) move the server and change forward DNS (set TTL low at first). Done. (restore TTL to longer value) Once you have FCrDNS (even with an unwanted PTR name), you should be able to safely move. Do some testing -- just hook some PC up to the new connection and use telnet (or the very handy mini_smtp tool) to send some test mails directly to various servers. I have a web server already over there that I can test from. What little I do web wise is not bothered by no rDNS. Now moving the DNS server itself will be a fun adventure. I already have all the zone files redone for the move. Configure postfix with a HELO name (smtp_helo_name) something like z9m9z.htt-consult.com rather than the more technically correct PTR name. Make sure the HELO hostname has an A record pointing to your IP. (bonus points for a name containing smtp, e?mail, mx, mta, etc.) This helps you look more like a mail server and less like a bot. Make sure you have an SPF record including your IP. If you use the same IP for sending and receiving, just include the spf mx key. (looks as if you have that already... good)
Re: Adding multiple headers
That would be appreciated.
On 4 Feb 2015 at 16:11, Wietse Venema wrote:
I have an unfinished implementation for multiple actions in access
maps or header/body_checks. Instead of prepend foo you would say
{prepend foo} {prepend bar}. This may be completed in the Postfix
3.1 development cycle.
Wietse
...don
support (at) microtechniques.com
Re: Working around recalcitrant ISP wrt rDNS
Am 04.02.2015 um 20:47 schrieb Robert Moskowitz: I have been 'working' with my new ISP for a couple weeks to get the rDNS setup for my server move (I am changing ISPs for a number of reasons). I was assured on signing that setting up rDNS was 'easy'; it is not. DIGing up the SOA on my IP rDNS tends to indicate that they have not updated that zone for many months. RDNS is a prerequisite *before* setupa MTA not the other direction And that 50-253-254-9-static.hfc.comcastbusiness.net has no RR (e.g. A or CNAME). Is there someway to get postfix to provide the needed inforation to the recipient MTA that this is OK and valid? you and your postfix are not in the position to provide any infromation i that context - the receiving MTA asks for the PTR of the connecting IP I am asking, but I suspect that even if I send out things OK, there will be MTAs out there that will not let their clients send mail to me as my rDNS does not match. it don't matter if it matches - if you are coming with such a PTR you are rejected - on my setup this is skipped at least if the envelope domain has a SPF policy listing that IP or if you are on one of 11 public DNSWL ptr-check.sh 50-253-254-9-static.hfc.comcastbusiness.net REJECT Generic DNS-Reverse-Lookup (PTR-Rule: 417) see http://www.emailtalk.org/ptr.aspx or configure http://en.wikipedia.org/wiki/Sender_Policy_Framework I am pushing the ISP that will remain unnamed. (oops. :) ) I was told that 'they are working on it'. Meanwhile I am paying double as I cannot migrate my server. 'they are working on it'? they are idiots - it takes 5 seconds to change the Reverse DNS for the IP to mail.htt-consult.com on their nameservers and the A-record is completly in your hands well, because i got tired about how long ISP's need for simple changes and then more than once *add* the requested PTR instead replace it and so email becomes a lottery i had a fight to get the reverse zone for our /24 delegated to my own nameservers and so now control each record as well as the TTL
Re: Adding multiple headers
On 2/4/2015 2:09 PM, System Support wrote: The PREPEND action can add a single header to outgoing mail. Is there a way to add multiple headers? ...don support (at) microtechniques.com Use the PREPEND action multiple times. -- Noel Jones
ot: hotmail bouncing since two days ago, is there some new requiremtns?
ot: I have Postfix running mail server for several small domains, all working well. since about 48 hours, several of my domains started getting bounced from hotmail as per below checked with mxtoolbox, mail server is: Checking emu.sbt.net.au which resolves to 103.15.178.123 against 100 known blacklists... Listed 0 times with 3 timeouts has hotmail changed or enforced something new in the last few days ? is there something I should do on my Postfix ? dns ? yesterday, I've added dns record as below, is that a must have ? TXT sbt.net.au 60 min v=spf1 a mx ~all -- Feb 5 07:06:45 emu postfix/smtp[32527]: EF7CC24E008: to=tt...@outlook.com, relay=mx3.hotmail.com[65.55.37.88]:25, delay=2.4, delays=0.49/0.04/1.6/0.19, dsn=5.0.0, status=bounced (host mx3.hotmail.com[65.55.37.88] said: 550 SC-001 (COL004-MC2F25) Unfortunately, messages from 103.15.178.123 weren't sent. Please contact your Internet service provider since part of their network is on our block list. You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors. (in reply to MAIL FROM command)) Feb 5 07:06:45 emu postfix/smtp[32527]: EF7CC24E008: lost connection with mx3.hotmail.com[65.55.37.88] while sending RCPT TO
Re: Working around recalcitrant ISP wrt rDNS
On 02/04/2015 03:51 PM, Noel Jones wrote: Which reminds me that the OP should register his domain and IP on dnswl.org (free and easy). -- Noel Jones thanks for the tip. Just one more action item.
Re: Adding multiple headers
System Support:
The PREPEND action can add a single header to outgoing mail. Is
there a way to add multiple
headers?
As implemented, there is one PREPEND action per rule, so you would
need multiple rules. If this is smtpd_mumble_restrictions you can
do one rule in smtpd_data_restrictions and one elsewhere (but not
smtpd_end_of_data_restrictions because by then the message is already
received).
You could use a Milter (Python, Perl, or other) to add any number
of headers.
I have an unfinished implementation for multiple actions in access
maps or header/body_checks. Instead of prepend foo you would say
{prepend foo} {prepend bar}. This may be completed in the Postfix
3.1 development cycle.
Wietse
Re: ot: hotmail bouncing since two days ago, is there some new requiremtns?
what exactly did you not understand in: Unfortunately, messages from 103.15.178.123 weren't sent. Please contact your Internet service provider since part of their network is on our block list. You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors; Am 04.02.2015 um 22:53 schrieb Voytek: ot: I have Postfix running mail server for several small domains, all working well. since about 48 hours, several of my domains started getting bounced from hotmail as per below checked with mxtoolbox, mail server is: Checking emu.sbt.net.au which resolves to 103.15.178.123 against 100 known blacklists... Listed 0 times with 3 timeouts has hotmail changed or enforced something new in the last few days ? is there something I should do on my Postfix ? dns ? yesterday, I've added dns record as below, is that a must have ? TXT sbt.net.au 60 min v=spf1 a mx ~all -- Feb 5 07:06:45 emu postfix/smtp[32527]: EF7CC24E008: to=tt...@outlook.com, relay=mx3.hotmail.com[65.55.37.88]:25, delay=2.4, delays=0.49/0.04/1.6/0.19, dsn=5.0.0, status=bounced (host mx3.hotmail.com[65.55.37.88] said: 550 SC-001 (COL004-MC2F25) Unfortunately, messages from 103.15.178.123 weren't sent. Please contact your Internet service provider since part of their network is on our block list. You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors. (in reply to MAIL FROM command)) Feb 5 07:06:45 emu postfix/smtp[32527]: EF7CC24E008: lost connection with mx3.hotmail.com[65.55.37.88] while sending RCPT TO
Re: Forwarding to Gmail
On Wed, Feb 04, 2015 at 08:39:05AM -0700, LuKreme wrote: Quite a few users are forwarding their mail to either yahoo or gmail, which is causing a lot of trouble because both services see spam being forwarded and blacklist the sending server (me). Gmail at least seems to calm down after a little while, but delays on some mail can be many hours. These are users who are setting their own forwarding up via postfixadmin and getting forwarded by postfix based on the mysql lookup in proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf, so the messages aren’t getting filtered at all (beyond what postscreen can do, of course). Is there anything that I can do about this on my end? Someway I can at least run spamassassin over the mail so I can not forward obvious spam? And if I AM forwarding obvious spam its at least marked as such by SA which might help. Hi, We run spamassassin against all Email, both sent and received by our mail systems. As a result of off-campus forwarding, we now deposit messages identified as spam in a sender specific outbound-spam folder. That together with blocking senders with excessive message counts per unit of time has helped keep us off the block/slow-down lists. For Yahoo, in particular, make certain you subscribe to their feedback loop and disable the forwarding for anyone who shows up, or educate them to just delete messages and not train them as spam. Otherwise, all mail sent to them can be blocked for an inconvenient amount of time. Regards, Ken
Re: Forwarding to Gmail
On 04 Feb 2015, at 08:45 , li...@rhsoft.net wrote: just setup SpamAssassin and ClamAV as *milter* and they are filtered unconditional until you define no_milters in master.cf for a specific service Ah, right, that sounds familiar. Reading documentation now. Thanks. -- Well, we know where we're goin' But we don't know where we've been And we know what we're knowin' But we can't say what we've seen
Re: ot: hotmail bouncing since two days ago, is there some new requiremtns?
On Thu, 5 Feb 2015 08:53:23 +1100 Voytek li...@sbt.net.au wrote: ot: I have Postfix running mail server for several small domains, all working well. since about 48 hours, several of my domains started getting bounced from hotmail as per below ... -- Feb 5 07:06:45 emu postfix/smtp[32527]: EF7CC24E008: to=tt...@outlook.com, relay=mx3.hotmail.com[65.55.37.88]:25, delay=2.4, delays=0.49/0.04/1.6/0.19, dsn=5.0.0, status=bounced (host mx3.hotmail.com[65.55.37.88] said: 550 SC-001 (COL004-MC2F25) Unfortunately, messages from 103.15.178.123 weren't sent. Please contact your Internet service provider since part of their network is on our block list. You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors. (in reply to MAIL FROM command)) Feb 5 07:06:45 emu postfix/smtp[32527]: EF7CC24E008: lost connection with mx3.hotmail.com[65.55.37.88] while sending RCPT TO Most likely one or more ip addresses at RACK Hosting are sending spam. Hotmail has decided to block an entire range of ip addresses and yours is included in that range. Your provider needs to address the issue of one or more of their users sending spam and then try to get Hotmail to stop blocking. I would contact my provider immediately and make them aware that Hotmail is blocking a range of their ips. -Thom
Re: PATCH: PIE for Postfix 3.1
On 02/05/2015 02:06 PM, Wietse Venema wrote: How do we know this makes a meaningful difference? Postfix programs appear to behave as usual with Fedora Core 20 and FreeBSD 9.x. The file command reports the executables as ELF 64-bit LSB shared object instead of ELF 64-bit LSB executable, so that looks right. There is a perl program, which comes packaged in most current distros, called hardening-check which outputs something like this: $ hardening-check ./postfix ./postfix: Position Independent Executable: yes Stack protected: no, not found! Fortify Source functions: unknown, no protectable libc functions used Read-only relocations: yes Immediate binding: no, not found! I must look into how to turn some of those other items into yes as well. If it is really that simple, then we might put PIE support into Postfix 3.0. That would be great. Peter
Re: PATCH: PIE for Postfix 3.1
On Wed, Feb 04, 2015 at 08:06:36PM -0500, Wietse Venema wrote: Usage: $ make makefiles pie=yes ... How do we know this makes a meaningful difference? Postfix programs appear to behave as usual with Fedora Core 20 and FreeBSD 9.x. The file command reports the executables as ELF 64-bit LSB shared object instead of ELF 64-bit LSB executable, so that looks right. Similar results here: pie=yes: postconf: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for NetBSD 6.1.4, not stripped pie=no: postconf: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for NetBSD 6.1.4, not stripped -- Viktor.
Re: PATCH: PIE for Postfix 3.1
Wietse Venema: Wietse Venema: Indeed. PIE support is a new feature. New features are not added during the code freeze. You're welcome to back-port this new feature once we have tested it in Postfix 3.1 with multiple build options (shared/nonshared) and with multiple OS distributions. This does not appear to require tests on multiple hardware architectures. Very lighty-tested patch follows. No INSTALL documentation until this has been tested. Usage: $ make makefiles pie=yes ... How do we know this makes a meaningful difference? Postfix programs appear to behave as usual with Fedora Core 20 and FreeBSD 9.x. The file command reports the executables as ELF 64-bit LSB shared object instead of ELF 64-bit LSB executable, so that looks right. If it is really that simple, then we might put PIE support into Postfix 3.0. Wietse
Re: PATCH: PIE for Postfix 3.1
On Wed, Feb 04, 2015 at 01:12:16PM -0500, Wietse Venema wrote:
Very lighty-tested patch follows. No INSTALL documentation until
this has been tested.
Usage: $ make makefiles pie=yes ...
Works on NETBSD6, with:
pie=yes shared=yes dynamicmaps=yes
pie=yes shared=no dynamicmaps=no
I also tested with a variant patch which uses -fPIE rather than
-fPIC to compile the object files when shared=no, because these
all end up in executables, rather than shared libraries. Rumour
has it that's the more correct thing to do in that case. This
also worked on NETBSD6. Slightly modified patch below (note the
$CCARGS to also match leading or trailing -fPI[CE])
--
Viktor.
diff --git a/makedefs b/makedefs
index f7be08c..618634d 100644
--- a/makedefs
+++ b/makedefs
@@ -105,6 +105,13 @@
# dynamicmaps=yes implicitly enables Postfix shared libraries.
#
# This feature was introduced with Postfix 3.0.
+# .IP \fBpie=yes\fR
+# .IP \fBpie=no\fR
+#
+# Enable (disable) Postfix builds with position-independent
+# executables, on platforms where this is supported.
+#
+# This feature was introduced with Postfix 3.1.
# .IP \fIinstallation_parameter\fB=\fIvalue\fR...
# Override the compiled-in default value of the specified
# installation parameter(s). The following parameters are
@@ -142,6 +149,7 @@ echo # CCARGS=$CCARGS
echo # AUXLIBS=$AUXLIBS
env | grep '^AUXLIBS_' | sed 's/^/# /'
echo # dynamicmaps=$dynamicmaps
+echo # pie=$pie
# Defaults for most sane systems
@@ -1082,6 +1090,24 @@ yes) SHLIB_SYSLIBS=`${AWK} '
'`
esac
+# Choose between PIE and non-PIE builds.
+
+case $pie in
+ yes)
+ case $shared in
+yes) CCARGS_PIE=-fPIC ;;
+ *) CCARGS_PIE=-fPIE ;;
+ esac
+ case $CCARGS in
+ * $CCARGS_PIE *) CCARGS_PIE= ;;
+ *) ;;
+ esac
+ SYSLIBS_PIE=-pie;;
+|no) ;;
+*) error Specify \pie=yes\ or \pie=no\;;
+esac
+
+
# Finally...
sed 's/ */ /g' EOF
@@ -1090,8 +1116,8 @@ SYSTYPE = $SYSTYPE
_AR= $_AR
ARFL = $ARFL
_RANLIB= $_RANLIB
-SYSLIBS= $AUXLIBS $SYSLIBS $PLUGIN_AUXLIBS
-CC = $CC $CCARGS \$(WARN)
+SYSLIBS= $SYSLIBS_PIE $AUXLIBS $SYSLIBS $PLUGIN_AUXLIBS
+CC = $CC $CCARGS_PIE $CCARGS \$(WARN)
OPT= $OPT
DEBUG = $DEBUG
AWK= $AWK
Re: PATCH: PIE for Postfix 3.1
Viktor Dukhovni: On Wed, Feb 04, 2015 at 01:12:16PM -0500, Wietse Venema wrote: Very lighty-tested patch follows. No INSTALL documentation until this has been tested. Usage: $ make makefiles pie=yes ... Works on NETBSD6, with: pie=yes shared=yes dynamicmaps=yes pie=yes shared=no dynamicmaps=no I also tested with a variant patch which uses -fPIE rather than -fPIC to compile the object files when shared=no, because these all end up in executables, rather than shared libraries. Rumour has it that's the more correct thing to do in that case. This also worked on NETBSD6. Slightly modified patch below (note the $CCARGS to also match leading or trailing -fPI[CE]) Good. I fixed one latent problem: case $shared in case $shared in Wietse
TUNING_README: persistent write cache?
Hello What does Speed up disk updates with a large (64MB) persistent write cache. mean (source: http://www.postfix.org/TUNING_README.html)? Does this talk about the dirty ratio or is it something else? Google didn't help me on this one. Thanks in advance! Best regards Andrew
Add header based on number of recipients
I have a sneaky spammer that is using compromised accounts of a mail server that relays outbound through my Postfix servers. The spammer is Bcc'ing 200 or 300 recipients at a time and sending very slowly to avoid my high volume detection. I need to be able to add a header that SpamAssassin can use to score based on a combination of other rules. I also want to maintain the privacy of the Bcc'd recipients. I am pretty sure this could be done in a milter but I was not able to find a milter out there that does this. I guess I could learn how to make a milter that just counts the recipients and add a header. I was thinking something like an X header that could be set to a value (Low, Medium, or High) based on a range of recipients. I could probably find a way to get Spamassassin to use the actual number of recipients with a plugin if that can be added easily by Postfix or a milter. P.S. In this instance, this spammer is sending out messages that don't score high in SA. I can usually block outbound spam but he is sending test/probe emails until they get through then blasting to a lot of Bcc recipients which gets us listed on RBLs. Also the original mail server is an Exchange server that does not add the X-Originating-IP or Received headers of the sender so I could key off of that in SA. Thanks, Dave
Re: Add header based on number of recipients
- Have you identified the e-mail server having those compromised accounts? If yes forbid this server to relay using your Postfix servers. If you don't want or cannot do it... - Then have you identified what e-mail accounts exactly are compromised? If yes temporarily close or disabled those accounts on the sending server. If you don't want or cannot do it... - And if sending accounts are identified, then instructs your Postfix servers to reject all what is sent through them by those compromised sender e-mail addresses... Preserve your reputation as sending system even if you've to temporarily forbid the sending server causing the SPAM to use your own servers. A behaviour of bot SPAM is that they send mass e-mails forging random recipient e-mail addresses. that means you probably get an unusual amount of bounces or deferred e-mails on your Postfix servers. You could find in your Postfix logs the sender e-mail addresses causing the most important part of bounces and/or deferred to identify the source of the attack and block it at Postfix level. If, as you wrote, it is a slow attack, a latent one, then try to find a tool that will be able to detect it and define Postfix policies on the fly as counter measures. You might find Postfix Policy Servers or daemons able to provide such kind of feature, like the X-Itools ELSE project with its RTAAM engine for example. Le 04/02/2015 14:34, Dave Jones a écrit : I have a sneaky spammer that is using compromised accounts of a mail server that relays outbound through my Postfix servers. The spammer is Bcc'ing 200 or 300 recipients at a time and sending very slowly to avoid my high volume detection. I need to be able to add a header that SpamAssassin can use to score based on a combination of other rules. I also want to maintain the privacy of the Bcc'd recipients. I am pretty sure this could be done in a milter but I was not able to find a milter out there that does this. I guess I could learn how to make a milter that just counts the recipients and add a header. I was thinking something like an X header that could be set to a value (Low, Medium, or High) based on a range of recipients. I could probably find a way to get Spamassassin to use the actual number of recipients with a plugin if that can be added easily by Postfix or a milter. P.S. In this instance, this spammer is sending out messages that don't score high in SA. I can usually block outbound spam but he is sending test/probe emails until they get through then blasting to a lot of Bcc recipients which gets us listed on RBLs. Also the original mail server is an Exchange server that does not add the X-Originating-IP or Received headers of the sender so I could key off of that in SA. Thanks, Dave attachment: hahnn.vcf
Tracking down a mail forwarding loop
I have a local user who is generating occasional mail forwarding loop errors, which are causing forged emails to cause NDNs and fill up mailq. Jan 30 13:46:08 mail postfix/local[44147]: 7020950D4D4: to=*bob*@covisp.net, relay=local, delay=0.65, delays=0.59/0/0/0.06, dsn=5.4.6, status=bounced (mail forwarding loop for *bob*@covisp.net) The only place that “*bob*” is mentioned in virtual is in line like this: bill...@covisp.net bob,fred,george Where bob, fred, and george are all local users. bob doesn’t have a .forward, and I looked at his .procmailrc and it’s not forwarding mail anywhere. Where else do I look? postmap -q b...@covisp.net /etc/postfix/virtual doesn’t return any results. -- Behind every great man there's a woman with a vibrator -- Hawkeye Pierce
Re: TUNING_README: persistent write cache?
Zitat von Andrew Bourgeois and...@demmel.be: Hello What does Speed up disk updates with a large (64MB) persistent write cache. mean (source: http://www.postfix.org/TUNING_README.html)? Does this talk about the dirty ratio or is it something else? Google didn't help me on this one. Thanks in advance! Best regards Andrew This allows disk updates to be sorted for optimal access speed without compromising file system integrity when the system crashes That's why you need a *persistant* cache, to not loose mail and get decent performance. Regards Andreas smime.p7s Description: S/MIME Cryptographic Signature
Re: TLS verification woes
On Wed, Feb 04, 2015 at 10:34:47AM +0100, Tobias Reckhard wrote: It's postfix-2.8.5 or, to be more precise, postfix-2.8.5-2~build0.10.04, and, as you assume, linked OpenSSL 0.9.8. I guess I'll have to relax the TLS policy for this domain until we can upgrade the system. If security to that site is important, you could use fingerprint by verifying their cert chain off-line and configuring static fingerprints on your side. But, this would have to be a short-term measure giving you time to upgrade to a more capable Postfix. The static fingerprints would have to be changed in sync any future update of their leaf certificates by the peer. -- Viktor.
Re: Tracking down a mail forwarding loop
LuKreme: I have a local user who is generating occasional mail forwarding loop errors, which are causing forged emails to cause NDNs and fill up mailq. Jan 30 13:46:08 mail postfix/local[44147]: 7020950D4D4: to=*bob*@covisp.net, relay=local, delay=0.65, delays=0.59/0/0/0.06, dsn=5.4.6, status=bounced (mail forwarding loop for *bob*@covisp.net) The only place that ?*bob*? is mentioned in virtual is in line like this: bill...@covisp.net bob,fred,george Where bob, fred, and george are all local users. bob doesn?t have a .forward, and I looked at his .procmailrc and it?s not forwarding mail anywhere. Where else do I look? Other opportunities for forwarding, such as postconf mailbox_command? Wietse
Re: Add header based on number of recipients
Dave Jones: I need to be able to relay outbound for this customer of ours as a service we provide and I need to be able to block compromised accounts which I have been successful at for years until this new spam technique showed up a few weeks ago. I do have a way to detect this Bcc sending _after the fact_ and put in a DISCARD for the sending address to stop the spam but some have already gotten out. When Bcc'ing 300 at a time, even a few getting out will create a lot of damage to our IP's reputation. Use postfwd, set a rule that triggers with too many recipients per SASL login. http://www.postfwd.org/ Wietse
Re: TUNING_README: persistent write cache?
Am 04.02.2015 um 15:40 schrieb Andrew Bourgeois: But what does persistent write cache mean? What needs to be changed on the OS level? Google doesn't clearly link persistent write cache to a Linux feature. https://www.google.at/#q=write+cache+storage https://www.google.at/search?q=bbu+storage
Re: Add header based on number of recipients
I need to be able to relay outbound for this customer of ours as a service we provide and I need to be able to block compromised accounts which I have been successful at for years until this new spam technique showed up a few weeks ago. I do have a way to detect this Bcc sending _after the fact_ and put in a DISCARD for the sending address to stop the spam but some have already gotten out. When Bcc'ing 300 at a time, even a few getting out will create a lot of damage to our IP's reputation. I need a way to detect the number of Bcc's in the headers to block them based on other characteristics. The problem is, all of the other characteristics are perfectly legit ways of sending mail without knowing the number of Bcc'd recipients. It's very common to send an email Bcc'ing a lot of recipients and putting your own address in the To: field. Spamassassin only sees the To: header as 1 recipient when there could be 300 Bcc'd. On Wed, Feb 4, 2015 at 7:57 AM, Nicolas HAHN ha...@erios.org wrote: - Have you identified the e-mail server having those compromised accounts? If yes forbid this server to relay using your Postfix servers. If you don't want or cannot do it... - Then have you identified what e-mail accounts exactly are compromised? If yes temporarily close or disabled those accounts on the sending server. If you don't want or cannot do it... - And if sending accounts are identified, then instructs your Postfix servers to reject all what is sent through them by those compromised sender e-mail addresses... Preserve your reputation as sending system even if you've to temporarily forbid the sending server causing the SPAM to use your own servers. A behaviour of bot SPAM is that they send mass e-mails forging random recipient e-mail addresses. that means you probably get an unusual amount of bounces or deferred e-mails on your Postfix servers. You could find in your Postfix logs the sender e-mail addresses causing the most important part of bounces and/or deferred to identify the source of the attack and block it at Postfix level. If, as you wrote, it is a slow attack, a latent one, then try to find a tool that will be able to detect it and define Postfix policies on the fly as counter measures. You might find Postfix Policy Servers or daemons able to provide such kind of feature, like the X-Itools ELSE project with its RTAAM engine for example. Le 04/02/2015 14:34, Dave Jones a écrit : I have a sneaky spammer that is using compromised accounts of a mail server that relays outbound through my Postfix servers. The spammer is Bcc'ing 200 or 300 recipients at a time and sending very slowly to avoid my high volume detection. I need to be able to add a header that SpamAssassin can use to score based on a combination of other rules. I also want to maintain the privacy of the Bcc'd recipients. I am pretty sure this could be done in a milter but I was not able to find a milter out there that does this. I guess I could learn how to make a milter that just counts the recipients and add a header. I was thinking something like an X header that could be set to a value (Low, Medium, or High) based on a range of recipients. I could probably find a way to get Spamassassin to use the actual number of recipients with a plugin if that can be added easily by Postfix or a milter. P.S. In this instance, this spammer is sending out messages that don't score high in SA. I can usually block outbound spam but he is sending test/probe emails until they get through then blasting to a lot of Bcc recipients which gets us listed on RBLs. Also the original mail server is an Exchange server that does not add the X-Originating-IP or Received headers of the sender so I could key off of that in SA. Thanks, Dave
Re: TUNING_README: persistent write cache?
But what does persistent write cache mean? What needs to be changed on the OS level? Google doesn't clearly link persistent write cache to a Linux feature. On Wed, Feb 4, 2015 at 2:16 PM, lst_ho...@kwsoft.de wrote: Zitat von Andrew Bourgeois and...@demmel.be: Hello What does Speed up disk updates with a large (64MB) persistent write cache. mean (source: http://www.postfix.org/TUNING_README.html)? Does this talk about the dirty ratio or is it something else? Google didn't help me on this one. Thanks in advance! Best regards Andrew This allows disk updates to be sorted for optimal access speed without compromising file system integrity when the system crashes That's why you need a *persistant* cache, to not loose mail and get decent performance. Regards Andreas
Re: Add header based on number of recipients
With postfwd you could use the following rule: id=RCPTCNT action=PREPEND X-RCPT-COUNT: $$recipient_count or something like that id=RCPTCNT01 recipient_count=200 action=PREPEND X-RCPT-COUNT: RED id=RCPTCNT02 recipient_count=100 action=PREPEND X-RCPT-COUNT: YELLOW Please note that postfwd must be used at DATA or END-OF-MESSAGE stage to get recipient_count reliably. cheers, jpk
Re: Tracking down a mail forwarding loop
On 04 Feb 2015, at 07:38 , Wietse Venema wie...@porcupine.org wrote: LuKreme: I have a local user who is generating occasional mail forwarding loop errors, which are causing forged emails to cause NDNs and fill up mailq. Jan 30 13:46:08 mail postfix/local[44147]: 7020950D4D4: to=*bob*@covisp.net, relay=local, delay=0.65, delays=0.59/0/0/0.06, dsn=5.4.6, status=bounced (mail forwarding loop for *bob*@covisp.net) The only place that ?*bob*? is mentioned in virtual is in line like this: bill...@covisp.net bob,fred,george Where bob, fred, and george are all local users. bob doesn?t have a .forward, and I looked at his .procmailrc and it?s not forwarding mail anywhere. Where else do I look? Other opportunities for forwarding, such as postconf mailbox_command”? Yeah, that’s why I checked procmailrc. I do see that the modification date on the procmailrc is quite recent. Maybe he munged something and got it fixed. I’ll keep watching. -- Growing up leads to growing old, and then to dying/And dying to me don't sound like all that much fun.
Re: TUNING_README: persistent write cache?
Andrew Bourgeois: But what does persistent write cache mean? What needs to be changed on the OS level? Google doesn't clearly link persistent write cache to a Linux feature. It is a hardware feature found in RAID controllers and in server I/O accelerators. The basic idea is to serialize random writes. SSHD disks may provide similar improvements with random I/O. Wietse
Re: Add header based on number of recipients
Thank you for the postfwd link. Not sure why I didn't find this during my research. I guess I didn't have the right Google keywords. :) On Wed, Feb 4, 2015 at 8:41 AM, Wietse Venema wie...@porcupine.org wrote: Dave Jones: I need to be able to relay outbound for this customer of ours as a service we provide and I need to be able to block compromised accounts which I have been successful at for years until this new spam technique showed up a few weeks ago. I do have a way to detect this Bcc sending _after the fact_ and put in a DISCARD for the sending address to stop the spam but some have already gotten out. When Bcc'ing 300 at a time, even a few getting out will create a lot of damage to our IP's reputation. Use postfwd, set a rule that triggers with too many recipients per SASL login. http://www.postfwd.org/ Wietse
Re: Forwarding to Gmail
Am 04.02.2015 um 16:39 schrieb LuKreme: Quite a few users are forwarding their mail to either yahoo or gmail, which is causing a lot of trouble because both services see spam being forwarded and blacklist the sending server (me). Gmail at least seems to calm down after a little while, but delays on some mail can be many hours. These are users who are setting their own forwarding up via postfixadmin and getting forwarded by postfix based on the mysql lookup in proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf, so the messages aren’t getting filtered at all (beyond what postscreen can do, of course) just setup SpamAssassin and ClamAV as *milter* and they are filtered unconditional until you define no_milters in master.cf for a specific service that way we have spamass-milter in front of the MX delivering to a dedicated port filtering incoming and already scanned messages to the final destinations while all other ports for submission are going through the outgoing spamass-milter with it's own rule configs
Re: Problems building 3.0 with dynamic module support
Viktor Dukhovni: On Wed, Feb 04, 2015 at 03:31:03PM +1300, Peter wrote: Well for now, then I'll just have to remove -pie, but if I can get that in as a feature request to make -pie work with shared=yes, then I would really appreciate it. Not sure if it should be considered a blocker for 3.0.0 or not, though, maybe it could be considered a bugfix to go into 3.0.1? We've never supported pie, so if shared libraries don't work with pie that's not a bug. Perhaps pie support could be considered for 3.1. Indeed. PIE support is a new feature. New features are not added during the code freeze. You're welcome to back-port this new feature once we have tested it in Postfix 3.1 with multiple build options (shared/nonshared) and with multiple OS distributions. This does not appear to require tests on multiple hardware architectures. Wietse
Re: Add header based on number of recipients
On 04/02/15 12:41, Wietse Venema wrote: Use postfwd, set a rule that triggers with too many recipients per SASL login. http://www.postfwd.org/ Wietse Policyd can also do that, check both. http://www.policyd.org/ -- Atenciosamente / Sincerily, Leonardo Rodrigues Solutti Tecnologia http://www.solutti.com.br Minha armadilha de SPAM, NÃO mandem email gertru...@solutti.com.br My SPAMTRAP, do not email it
Receiving email from Everbridge alert systems
I'm sure there are other Postfix sites which have looked into the question of what is required for Everbridge email to come in without potential delays or non-delivery. I'm asking someone working with our contact at Everbridge for a list of IPs which are used on their end, as I've found there are DNS issues and greylisting flagged one of their SMTP for not re-connecting within 24 hours. There is also the rate limit we'd like to exempt for their IPs. I can whitelist their IPs in sqlgreylist and in check_client_access hash:/etc/postfix/access as well as the DNSRBL. I'm not aware we can introduce exemptions for smtpd_client_connection_rate_limit smtpd_client_message_rate_limit If anyone has already tweaked Postfix to accommodate the Everbridge alert system, do you want to share what helped?
Forwarding to Gmail
Quite a few users are forwarding their mail to either yahoo or gmail, which is causing a lot of trouble because both services see spam being forwarded and blacklist the sending server (me). Gmail at least seems to calm down after a little while, but delays on some mail can be many hours. These are users who are setting their own forwarding up via postfixadmin and getting forwarded by postfix based on the mysql lookup in proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf, so the messages aren’t getting filtered at all (beyond what postscreen can do, of course). Is there anything that I can do about this on my end? Someway I can at least run spamassassin over the mail so I can not forward obvious spam? And if I AM forwarding obvious spam its at least marked as such by SA which might help. The gmail issues are mailq entries that look like this: D210621494D12700 Tue Feb 3 21:30:55 n...@dontyoudropthat.com (host alt1.gmail-smtp-in.l.google.com[74.125.22.26] said: 421-4.7.0 [75.148.37.66 15] Our system has detected an unusual rate of 421-4.7.0 unsolicited mail originating from your IP address. To protect our 421-4.7.0 users from spam, mail sent from your IP address has been temporarily 421-4.7.0 rate limited. Please visit 421-4.7.0 http://www.google.com/mail/help/bulk_mail.html to review our Bulk 421 4.7.0 Email Senders Guidelines. z39si14220069gz.97 - gsmtp (in reply to end of DATA command)) That message eventually delivered at 03:09 today. Now, in this case it looks like it was probably spam and so the delay doesn’t matter, but sometimes the mail that is delayed is not spam. The only thing I can say at this point is “Google is delaying your mail” which is true, but not very useful. -- There is a road, no simple highway, between the dawn and the dark of night
Re: Receiving email from Everbridge alert systems
Am 04.02.2015 um 16:30 schrieb francis picabia: I'm not aware we can introduce exemptions for smtpd_client_connection_rate_limit smtpd_client_message_rate_limit If anyone has already tweaked Postfix to accommodate the Everbridge alert system, do you want to share what helped? you can easily implement rate controls with iptables recent and remove specific IP's or subnets bevor apply the rule - IMHO connection ratecontrols belongs anyways to the network / firewall layer and not in the application layer at all iptables -I INPUT -p tcp --dport 25 -m conntrack --ctstate NEW -m recent --name postfix1 --set iptables -I INPUT -p tcp -s $SOURCE_RANGE -m conntrack --ctstate NEW -m recent --remove iptables -I INPUT -p tcp --dport 25 -m conntrack --ctstate NEW -m recent --name postfix1 --update --seconds 1800 --hitcount 60 -j REJECT iptables -I INPUT -p tcp --dport 25 -m conntrack --ctstate NEW -m recent --name postfix1 --update --seconds 1800 --hitcount 60 -m limit --limit 60/h -j LOG --log-prefix Firewall Rate-Control:
Re: Forwarding to Gmail
On 04/02/15 13:39, LuKreme wrote: Quite a few users are forwarding their mail to either yahoo or gmail, which is causing a lot of trouble because both services see spam being forwarded and blacklist the sending server (me). Gmail at least seems to calm down after a little while, but delays on some mail can be many hours. These are users who are setting their own forwarding up via postfixadmin and getting forwarded by postfix based on the mysql lookup in proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf, so the messages aren’t getting filtered at all (beyond what postscreen can do, of course). Is there anything that I can do about this on my end? Edit postfixadmin WebUI and deny forwarding to gmail/yahoo ?? Seriously, there's not much you can do about what the remote server decides to do with your mail. Are you doing SRS before forwarding to remote servers ? If not, and probably you're not, then at least you're hitting hard on the SPF fail tests that gmail should be running and, thus, that is increasing your 'spam score'. -- Atenciosamente / Sincerily, Leonardo Rodrigues Solutti Tecnologia http://www.solutti.com.br Minha armadilha de SPAM, NÃO mandem email gertru...@solutti.com.br My SPAMTRAP, do not email it
Re: PATCH: PIE for Postfix 3.1
On Thu, Feb 05, 2015 at 01:04:58AM +, Viktor Dukhovni wrote: On Wed, Feb 04, 2015 at 01:12:16PM -0500, Wietse Venema wrote: Very lighty-tested patch follows. No INSTALL documentation until this has been tested. Usage: $ make makefiles pie=yes ... Works on NETBSD6, with: pie=yes shared=yes dynamicmaps=yes pie=yes shared=no dynamicmaps=no I also tested with a variant patch which uses -fPIE rather than -fPIC to compile the object files when shared=no, because these all end up in executables, rather than shared libraries. Rumour has it that's the more correct thing to do in that case. This also worked on NETBSD6. Slightly modified patch below (note the $CCARGS to also match leading or trailing -fPI[CE]) MacOS/X (Mavericks) testing reveals that with Apple's llvm/clang, shared=yes yields PIE executables by default with no -pie option required. $ otool -hv bin/postconf bin/postconf: Mach header magic cputype cpusubtype capsfiletype ncmds sizeofcmds flags MH_MAGIC_64 X86_64ALL LIB64 EXECUTE21 2120 DYLDLINK PIE In fact attempts to use an explicit -pie option yield warnings: clang: warning: argument unused during compilation: '-pie' this warning is fatal if one includes -Werror in CCARGS. It is possible, but redundant to include -Wl,-pie when building with shared=yes or when objects are compiled with -fPIE, as in both cases the generated executable is automatically PIE. Even with shared=no and pie=no I still get PIE executables. So we should perhaps just ignore the pie option with MacOS/X. Have not tried Yosetime yet... -- Viktor.
