* Viktor Dukhovni postfix-us...@dukhovni.org:
On Thu, Nov 07, 2013 at 08:58:47PM -0600, Stan Hoeppner wrote:
This would require too much complex code for what is a simple Postfix
operation. Your example is poor man's round robin. That's the best
Postfix can do without serious code
On 08 Nov 2013, at 01:34, Stan Hoeppner s...@hardwarefreak.com wrote:
On 11/7/2013 5:53 AM, Simon Loewenthal wrote:
Damned chroot now turned off, and lookups now work like they should have
done :D
The default Postfix chroot environment in Debian 6 Squeeze works fine
out of the box, as
Am 08.11.2013 10:42, schrieb DTNX Postmaster:
$ cat /usr/share/doc/postfix/README.Debian
There are some significant differences between the Debian Postfix packages,
and the source from upstream:
1. The Debian install is chrooted by default.
2. Dynamically loadable map support.
3. For
Hi All
I've just bought a new postfix mail server online.
It seems to be mostly working, however occasionally I'm seeing messages in
mail.log saying
imapd-ssl: couriertls: read: No route to host
I've googled it, but just can't find anything particularly meaningful.
I'm not sure if this is
Roman Gelfand:
Wouldn't the server be chosen round robin as opposed to random?
Postfix delivers messages in parallel. Because each SMTP client
process chooses a server IP address independently, it must be
selected randomly.
Wietse
mark hardwick:
Hi All
I've just bought a new postfix mail server online.
It seems to be mostly working, however occasionally I'm seeing messages in
mail.log saying
imapd-ssl: couriertls: read: No route to host
Your TCP/IP stack received an ICMP host unreachable error packet:
#define
Hi All
Pretty much everything is working with my new mail server now.
Google, hotmail etc are all chatting nicely to me, AOL on the other had just
says
postfix/smtp[31792]: 3DDC64827D: host mailin-03.mx.aol.com[205.188.156.193]
refused to talk to me: 421 mtain-dl02.r1000.mx.aol.com Service
Am 08.11.2013 13:45, schrieb mark hardwick:
Pretty much everything is working with my new mail server now.
Google, hotmail etc are all chatting nicely to me, AOL on the other had just
says
postfix/smtp[31792]: 3DDC64827D: host mailin-03.mx.aol.com[205.188.156.193]
refused to talk to me:
Tobi:
Am 07.11.2013 23:55, schrieb Viktor Dukhovni:
On Thu, Nov 07, 2013 at 11:46:43PM +0100, Tobi wrote:
If the ip/port are different, it is not the *SAME* configuration.
I know but it's not possible otherwise. The two other server reach
the mysql-cluster via other ips/ports.
Do
Am 07.11.2013 23:55, schrieb Viktor Dukhovni:
On Thu, Nov 07, 2013 at 11:46:43PM +0100, Tobi wrote:
If the ip/port are different, it is not the *SAME* configuration.
I know but it's not possible otherwise. The two other server reach
the mysql-cluster via other ips/ports.
Do double-check that
On Fri, Nov 08, 2013 at 03:45:03PM +0100, Tobi wrote:
The error message is 99.999% not from mysql. Because when I remove the
backticks around the table name then I get an error from mysql which
looks different
That error is also from MySQL. Postfix does not parse SQL queries,
the database
Am 08.11.2013 15:59, schrieb Wietse Venema:
Tobi:
Am 07.11.2013 23:55, schrieb Viktor Dukhovni:
On Thu, Nov 07, 2013 at 11:46:43PM +0100, Tobi wrote:
If the ip/port are different, it is not the *SAME* configuration.
I know but it's not possible otherwise. The two other server reach
the
Am 08.11.2013 16:18, schrieb Viktor Dukhovni:
On Fri, Nov 08, 2013 at 03:45:03PM +0100, Tobi wrote:
The error message is 99.999% not from mysql. Because when I remove the
backticks around the table name then I get an error from mysql which
looks different
That error is also from MySQL.
On 07 Nov 2013, at 16:18 , Jeroen Geilman jer...@adaptr.nl wrote:
postfix - LMTP - dspam - LMTP - dovecot
That sounds kind of interesting. I tried to do something like this with
SpamAssassin, but the overhead was too significant. Might work better now that
we have postscreen rejecting 95%
Hello all,
I'm running postfix-2.9.6 on Ubuntu Server 12.04 LTS amd64.
I recently ran across a bug in postfix's milter implementation, shortly
after switching the server it was running on from sendmail to postfix.
This milter removes recipients that aren't in a whitelist, so I keep a
list of
moparisthebest:
Hello all,
I'm running postfix-2.9.6 on Ubuntu Server 12.04 LTS amd64.
Please send postconf -n output, SMTP command/reply transcript,
and NON-VERBOSE logging.
Wietse
I recently ran across a bug in postfix's milter implementation, shortly
after switching the server
I've gathered some example logs, output of postconf -n, and the milter
implementation here:
http://www.moparisthebest.com/pfix/
The python code is a little to lengthy to inline, so a direct link is here:
http://www.moparisthebest.com/pfix/testmilter.py
And I'll go ahead and inline the other
moparisthebest:
# try 2, should be filtered but isn't
# smtp email addressed to 'g...@example.org b...@example.org'
...
# milter log
[14:06:56] Connect from 127.0.0.1:48029 (localhost) with family: 4
[14:06:56] MAIL FROM: m...@example.org
[14:06:56] RCPT TO: g...@example.org
A strange issue indeed, this exact same python code is running on
another server with sendmail and works fine, as you can see from the
testmilter.py log:
[15:19:07] Connect from 127.0.0.1:37841 (localhost) with family: 4
[15:19:07] MAIL FROM: m...@example.org
[15:19:08] RCPT TO: g...@example.org
moparisthebest:
I went ahead and ran:
tcpdump -w /tmp/log.txt -i lo -s 0 host 127.0.0.1 and port 5001
on both servers to see what was actually sent back and forth from
sendmail/postfix to the python milter, and discovered packets from
sendmail contain:
{rcpt_addr}b...@example.org
Hi,
my transport_maps is:
transport_maps = hash:/etc/postfix/transport,
regexp:/etc/postfix/transport.exp,
tcp:[127.0.0.1]:2527
I want to use the tcp as last resort lookup but I don't know in
which order postfix is checking everything.
It looks like it is doing:
first round:
check
Simon Effenberg:
Hi,
my transport_maps is:
transport_maps = hash:/etc/postfix/transport,
regexp:/etc/postfix/transport.exp,
tcp:[127.0.0.1]:2527
I want to use the tcp as last resort lookup but I don't know in
which order postfix is checking everything.
transport_maps are searched
wie...@porcupine.org schrieb:
transport_maps are searched in the order as specified in main.cf.
If it's not found in regexp:/etc/postfix/transport.exp, then
the tcp map is queried.
Wietse
So this means that I cannot distinguish between x...@yyy.com and yyy.com
lookups in the tcp
On 11/8/2013 4:05 AM, li...@rhsoft.net wrote:
there are only rare situations where a chrooted postfix
makes sense and so they should not making a problematic
default which gains nothing on 999 out of 1000 setups
The reason for chrooting Postfix is due to a Debian policy established
lng
If lookup fails Postfix will use default transport.
On Nov 9, 2013 7:49 AM, Simon Effenberg sa...@schuldeigen.de wrote:
wie...@porcupine.org schrieb:
transport_maps are searched in the order as specified in main.cf.
If it's not found in regexp:/etc/postfix/transport.exp, then
the tcp map
Hello
Today while checking security I stumbled upon a weird spoof problem.
I have enabled SPF checking and and reject_sender_login_mismatch and
everything works.
But, If I try to send email from an external SMTP server and try to spoof as
shown below, all my SPF and stuff checks will fail.
Found the problem
I am using check_recipient_access and for some reason I had a line with bad
code.
Fixed it and now it works
Inside the hash file I have:
domain.tld REJECT Reason for reject
--
View this message in context:
One more problem I spotted while having this situation is that SPF checking
is not done automagically for subdomains. I learn something new everyday.
You have domain.tld and SPF setup with -all
If your FQDN is mail.domain.tld, there will be no SPF check for it in case
of spoofing.
To counter
28 matches
Mail list logo
