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 this
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:
http://postfix.1071664.n5.nabble.com/Strange-spoof-problem-tp62
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.
Inform
If lookup fails Postfix will use default transport.
On Nov 9, 2013 7:49 AM, "Simon Effenberg" 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 is queri
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
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
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
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:
che
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
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:
> # 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
> [1
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 tw
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 s
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 rec
On 07 Nov 2013, at 16:18 , Jeroen Geilman 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% or more of a
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 MySQ
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 serve
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 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-c
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/po
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 t
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 unava
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:
#defi
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
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 somet
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
On 08 Nov 2013, at 01:34, Stan Hoeppner 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 did Lenny. You
* Viktor Dukhovni :
> 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 changes. But why add suc
28 matches
Mail list logo
