RE: postscreen vs. fail2ban

[Michael Fox]

Sebastian, Wietse, Noel:  thanks for your responses re Postscreen vs.
Fail2ban.

Michael

Re: About table search order: not to query 'user+extens...@domain.ltd'

[Viktor Dukhovni]

On Wed, Mar 11, 2015 at 11:32:43PM +0800, Zhang Huangbin wrote:
> Dear all,
> 
> According to Postfix document, virtual(8), 'user+extens...@domain.ltd'
> is looked up first, then 'u...@domain.ltd'. Is it possible to
> skip/ignore the address extension and just query 'u...@domain.ltd'?
> (by the way, i want to ignore the extension in SQL/LDAP lookup.)

Not at present.  You can only suppress lookups for bare keys which
can happen when the domain is $myorigin or matches $mydestination
by interpolating the lookup key into the query via '%u@%d' instead
of '%s'.  That will filter out keys with no @domain part.

This logic happens in the *SQL and LDAP table drivers, while the
sequencing of lookup keys happens above that layer, and is not
currently configurable.  Configurable case-folding and lookup key
selection is not currently implemented.

-- 
Viktor.

Re: SMTP AUTH issue

[Emmanuel Fusté]

Le 11/03/2015 16:39, Viktor Dukhovni a écrit :

On Wed, Mar 11, 2015 at 01:41:00PM +0100, Emmanuel Fust? wrote:


Hello,

On a heavy i/o loaded Postfix (2.11.0) server, i've got this behavior:

535 5.7.8 Error: authentication failed: Connection lost to authentication server
Mar 10 16:37:08 x postfix/smtpd[20613]: warning: x.x.x[x.x.x.x]: SASL 
CRAM-MD5 authentication failed: Connection lost to authentication server

Ok, I have an i/o load problem with this server, but a 535 error code is too 
much, I was expecting a 454 error code as stated in RFC2554.

A complete solution would require handling similar problems for
Cyrus SASL, but I never got a meaningful response to:

 http://archives.neohapsis.com/archives/postfix/2008-12/0405.html
 https://www.mail-archive.com/postfix-users@postfix.org/msg56129.html

You could try the patch below and report your results (presumably
for Dovecot).  It would be nice to have confirmation for Cyrus
also.


Thank you !

Will test and report the result asap.

Regards,
Emmanuel.

Re: About table search order: not to query 'user+extens...@domain.ltd'

[Viktor Dukhovni]

On Wed, Mar 11, 2015 at 11:55:31PM +0800, Zhang Huangbin wrote:
> On Wed, Mar 11, 2015 at 11:46 PM, Viktor Dukhovni
>  wrote:
> >
> > Not at present.  You can only suppress lookups for bare keys which
> > can happen when the domain is $myorigin or matches $mydestination
> > by interpolating the lookup key into the query via '%u@%d' instead
> > of '%s'.  That will filter out keys with no @domain part.
> 
> Thanks Victor. :)
> 
> I'm afraid that '%u' doesn't work, it still has '+extension' in query.
> for example:

I did not say it would solve your problem.  It addresses a different
need.

> As you can see, '%u' doesn't drop extension '+abc' in my test.
> Anything wrong in my testing?

No, that's what %u is supposed to do.

You may well be able to do something with advanced SQL string
manipulation to short-circuit queries that contain "+".

SELECT result
FROM table
WHERE key = '%u@%d' 
AND key NOT LIKE '%%+%%'

An SQL server may well optimize that query away when the key contains
a "+" and not do any disk I/O.

-- 
Viktor.

Re: About table search order: not to query 'user+extens...@domain.ltd'

[Zhang Huangbin]

On Thu, Mar 12, 2015 at 12:10 AM, Viktor Dukhovni
 wrote:

>> In this case, SQL is flexible. but any solution for LDAP table? we cannot do
>> this in ldap query filter.
>
> No.

OK, thanks.

BTW, any plan to support this (ignore '+extension' in table lookup)?

Re: Tracking down www-data email sender

[Benny Pedersen]

On March 12, 2015 5:14:12 AM Robin Rowe  wrote:


Suggestions? How do I track it down?


remove this email in wordpress, solved

header_checks not working

[Krinninger, Reinhold]

Hello,

i'm trying to stop some spammails with a header_check. The header_check looks 
for the hostname of our smtp-server in the "From:"-Line in the headers of 
incoming mail. I want to reject all Mails with this or similar "From:" Lines:

From: "DHL Team" 
m8148012...@itmu-smtp2.br.de

Where "itmu-smtp2.br.de" is the hostname of our smtp-server.

i use this header_check:
/etc/postfix/header_checks:
/^From: (?!.*\/ REJECT seems to be spam, isn't 
it?
/^From: .*\@.*/ WARN

the first line should reject all spammails as described above, the second line 
should log all "From: " lines in the maillog with a warning from all mails, 
which passed the first line.
What i see is, that the second line works as expected, the problem is the first 
line. None of the spammails with this or similar "From:"-Lines gets rejected 
and I see no message in the message-log. When i try local with telnet or a 
mailclient the header_check works as expected and the testmail gets rejected. I 
have no idea whats wrong, any ideas from you would appreciated.
We use Postfix 2.11 on RHEL6 64bit.

Best Regards
Reinhold Krinninger


--
Bayerischer Rundfunk; Rundfunkplatz 1; 80335 München
Telefon: +49 89 590001; E-Mail: i...@br.de; Website: http://www.BR.de

Re: header_checks not working

[nicolas]

El 2015-03-12 12:31, Krinninger, Reinhold escribió:

Hello,

i use this header_check:



I assume that you're actually using header_checks (ended in **s**) and 
that your table type is regex: in order this to work.



/etc/postfix/header_checks:

/^From: (?!.*\/  REJECT seems to be 
spam,

isn't it?



Why not a bit simpler?

/^From: (?!/ REJECT seems to be spam, isn't 
it?


Regards,

Nicolás

Re: header_checks not working

[Noel Jones]

On 3/12/2015 7:31 AM, Krinninger, Reinhold wrote:
> Hello,
> 
>  
> 
> i'm trying to stop some spammails with a header_check. The
> header_check looks for the hostname of our smtp-server in the
> "From:"-Line in the headers of incoming mail. I want to reject all
> Mails with this or similar "From:" Lines:
> 
>  
> 
> From: "DHL Team" m8148012...@itmu-smtp2.br.de
> 
> 
>  
> 
> Where "itmu-smtp2.br.de" is the hostname of our smtp-server.
> 
>  
> 
> i use this header_check:
> 
> /etc/postfix/header_checks:
> 
> /^From: (?!.*\/ REJECT seems to be
> spam, isn't it?

Simplify...
/^From: .*root@itu-smtp2\.br\.de/  WARN
/^From: .*@itu-smtp2\.br\.de/  REJECT invalid hostname in From: header

> 
> /^From: .*\@.*/ WARN

/^From: / WARN

> 
>  
> 
> the first line should reject all spammails as described above, the
> second line should log all "From: " lines in the maillog with a
> warning from all mails, which passed the first line.
> 
> What i see is, that the second line works as expected, the problem
> is the first line. None of the spammails with this or similar
> "From:"-Lines gets rejected and I see no message in the message-log.
> When i try local with telnet or a mailclient the header_check works
> as expected and the testmail gets rejected. I have no idea whats
> wrong, any ideas from you would appreciated.
> 
> We use Postfix 2.11 on RHEL6 64bit.
> 
>  
> 
> Best Regards
> 
> Reinhold Krinninger
> 
>  
> 
>  
> 
> 
> --
> 
> 
> 
> Bayerischer Rundfunk; Rundfunkplatz 1; 80335 München
> 
> 
> Telefon: +49 89 590001; E-Mail: i...@br.de; Website: http://www.BR.de
> 
> 

Incorrect postscreen documentation

[Quanah Gibson-Mount]

Says that postscreen_dnsbl_timeout is available in Postfix 2.11 or later. 
This is not correct.  It is in postfix 3.0 and later.


--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration

External forwards and dovecot-lda

[Rod K]

I'm currently configuring a new server using Postfix/Dovecot.  My 
previous experience is with Courier and I've been using Postfix's 
virtual lda.  I want to start using dovecot-lda.


Here's the issue, I have several external forwards such as 
joeb...@internal.tld > joeb...@external.tld where external.tld is NOT 
hosted by me obviously.  Of course, I also have internal 
aliases/forwards as well (janeb...@internal.tld > 
someonee...@internal.tld and joe...@internal.tld > 
joe...@anotherinternal.tld)  Utilizing postfix virtual lda this wasn't 
an issue, both internal and external forwards/aliases worked fine.


If I understand Dovecot lda correctly, I need to rewrite internal 
forwards/aliases before sending to Dovecot AND I need to have external 
forwards sent to Postfix virtual and this is the part I'm not clear on.  
Unless I've missed something there doesn't seem to be a way to define 
transport on a per address basis.  Or am I totally thinking about this 
the wrong way?


Thanks

Re: External forwards and dovecot-lda

[Noel Jones]

On 3/12/2015 5:28 PM, Rod K wrote:
> I'm currently configuring a new server using Postfix/Dovecot.  My
> previous experience is with Courier and I've been using Postfix's
> virtual lda.  I want to start using dovecot-lda.
> 
> Here's the issue, I have several external forwards such as
> joeb...@internal.tld > joeb...@external.tld where external.tld is
> NOT hosted by me obviously.  Of course, I also have internal
> aliases/forwards as well (janeb...@internal.tld >
> someonee...@internal.tld and joe...@internal.tld >
> joe...@anotherinternal.tld)  Utilizing postfix virtual lda this
> wasn't an issue, both internal and external forwards/aliases worked
> fine.
> 
> If I understand Dovecot lda correctly, I need to rewrite internal
> forwards/aliases before sending to Dovecot AND I need to have
> external forwards sent to Postfix virtual and this is the part I'm
> not clear on.  Unless I've missed something there doesn't seem to be
> a way to define transport on a per address basis.  Or am I totally
> thinking about this the wrong way?
> 
> Thanks

Put your local and external aliases in virtual_alias_maps (*NOT*
virtual_alias_domains) and it will work fine.  No need to muck
around with the postfix virtual transport.



  -- Noel Jones

Re: External forwards and dovecot-lda

[Rod K]

On 3/12/2015 6:35 PM, Noel Jones wrote:

On 3/12/2015 5:28 PM, Rod K wrote:

I'm currently configuring a new server using Postfix/Dovecot.  My
previous experience is with Courier and I've been using Postfix's
virtual lda.  I want to start using dovecot-lda.

Here's the issue, I have several external forwards such as
joeb...@internal.tld > joeb...@external.tld where external.tld is
NOT hosted by me obviously.  Of course, I also have internal
aliases/forwards as well (janeb...@internal.tld >
someonee...@internal.tld and joe...@internal.tld >
joe...@anotherinternal.tld)  Utilizing postfix virtual lda this
wasn't an issue, both internal and external forwards/aliases worked
fine.

If I understand Dovecot lda correctly, I need to rewrite internal
forwards/aliases before sending to Dovecot AND I need to have
external forwards sent to Postfix virtual and this is the part I'm
not clear on.  Unless I've missed something there doesn't seem to be
a way to define transport on a per address basis.  Or am I totally
thinking about this the wrong way?

Thanks

Put your local and external aliases in virtual_alias_maps (*NOT*
virtual_alias_domains) and it will work fine.  No need to muck
around with the postfix virtual transport.



   -- Noel Jones
That's what I initially thought.  However, wouldn't external forwards 
still get passed to Dovecot which then couldn't deliver?

Re: External forwards and dovecot-lda

[Noel Jones]

On 3/12/2015 5:50 PM, Rod K wrote:
> On 3/12/2015 6:35 PM, Noel Jones wrote:
>> On 3/12/2015 5:28 PM, Rod K wrote:
>>> I'm currently configuring a new server using Postfix/Dovecot.  My
>>> previous experience is with Courier and I've been using Postfix's
>>> virtual lda.  I want to start using dovecot-lda.
>>>
>>> Here's the issue, I have several external forwards such as
>>> joeb...@internal.tld > joeb...@external.tld where external.tld is
>>> NOT hosted by me obviously.  Of course, I also have internal
>>> aliases/forwards as well (janeb...@internal.tld >
>>> someonee...@internal.tld and joe...@internal.tld >
>>> joe...@anotherinternal.tld)  Utilizing postfix virtual lda this
>>> wasn't an issue, both internal and external forwards/aliases worked
>>> fine.
>>>
>>> If I understand Dovecot lda correctly, I need to rewrite internal
>>> forwards/aliases before sending to Dovecot AND I need to have
>>> external forwards sent to Postfix virtual and this is the part I'm
>>> not clear on.  Unless I've missed something there doesn't seem to be
>>> a way to define transport on a per address basis.  Or am I totally
>>> thinking about this the wrong way?
>>>
>>> Thanks
>> Put your local and external aliases in virtual_alias_maps (*NOT*
>> virtual_alias_domains) and it will work fine.  No need to muck
>> around with the postfix virtual transport.
>>
>>
>>
>>-- Noel Jones
> That's what I initially thought.  However, wouldn't external
> forwards still get passed to Dovecot which then couldn't deliver?

No, of course not.  External domains are delivered via the smtp
transport.

This assumes a fairly normal postfix installation, with dovecot
domains listed in virtual_alias_domains, and valid users in
virtual_mailbox_maps.
http://www.postfix.org/ADDRESS_CLASS_README.html




  -- Noel Jones

Re: External forwards and dovecot-lda

[Noel Jones]

On 3/12/2015 6:03 PM, Noel Jones wrote:
> On 3/12/2015 5:50 PM, Rod K wrote:
>> On 3/12/2015 6:35 PM, Noel Jones wrote:
>>> On 3/12/2015 5:28 PM, Rod K wrote:
 I'm currently configuring a new server using Postfix/Dovecot.  My
 previous experience is with Courier and I've been using Postfix's
 virtual lda.  I want to start using dovecot-lda.

 Here's the issue, I have several external forwards such as
 joeb...@internal.tld > joeb...@external.tld where external.tld is
 NOT hosted by me obviously.  Of course, I also have internal
 aliases/forwards as well (janeb...@internal.tld >
 someonee...@internal.tld and joe...@internal.tld >
 joe...@anotherinternal.tld)  Utilizing postfix virtual lda this
 wasn't an issue, both internal and external forwards/aliases worked
 fine.

 If I understand Dovecot lda correctly, I need to rewrite internal
 forwards/aliases before sending to Dovecot AND I need to have
 external forwards sent to Postfix virtual and this is the part I'm
 not clear on.  Unless I've missed something there doesn't seem to be
 a way to define transport on a per address basis.  Or am I totally
 thinking about this the wrong way?

 Thanks
>>> Put your local and external aliases in virtual_alias_maps (*NOT*
>>> virtual_alias_domains) and it will work fine.  No need to muck
>>> around with the postfix virtual transport.
>>>
>>>
>>>
>>>-- Noel Jones
>> That's what I initially thought.  However, wouldn't external
>> forwards still get passed to Dovecot which then couldn't deliver?
> 
> No, of course not.  External domains are delivered via the smtp
> transport.
> 
> This assumes a fairly normal postfix installation, with dovecot
> domains listed in virtual_alias_domains, and valid users in
> virtual_mailbox_maps.

Dang, mistyped...  Dovecot domains should be listed in
virtual_mailbox_domains, NOT virtual_alias_domains.



  -- Noel Jones


> http://www.postfix.org/ADDRESS_CLASS_README.html
> 
> 
> 
> 
>   -- Noel Jones
> 

Re: External forwards and dovecot-lda

[Rod K]

On 3/12/2015 7:06 PM, Noel Jones wrote:

On 3/12/2015 6:03 PM, Noel Jones wrote:

On 3/12/2015 5:50 PM, Rod K wrote:

On 3/12/2015 6:35 PM, Noel Jones wrote:

On 3/12/2015 5:28 PM, Rod K wrote:

I'm currently configuring a new server using Postfix/Dovecot.  My
previous experience is with Courier and I've been using Postfix's
virtual lda.  I want to start using dovecot-lda.

Here's the issue, I have several external forwards such as
joeb...@internal.tld > joeb...@external.tld where external.tld is
NOT hosted by me obviously.  Of course, I also have internal
aliases/forwards as well (janeb...@internal.tld >
someonee...@internal.tld and joe...@internal.tld >
joe...@anotherinternal.tld)  Utilizing postfix virtual lda this
wasn't an issue, both internal and external forwards/aliases worked
fine.

If I understand Dovecot lda correctly, I need to rewrite internal
forwards/aliases before sending to Dovecot AND I need to have
external forwards sent to Postfix virtual and this is the part I'm
not clear on.  Unless I've missed something there doesn't seem to be
a way to define transport on a per address basis.  Or am I totally
thinking about this the wrong way?

Thanks

Put your local and external aliases in virtual_alias_maps (*NOT*
virtual_alias_domains) and it will work fine.  No need to muck
around with the postfix virtual transport.



-- Noel Jones

That's what I initially thought.  However, wouldn't external
forwards still get passed to Dovecot which then couldn't deliver?

No, of course not.  External domains are delivered via the smtp
transport.

This assumes a fairly normal postfix installation, with dovecot
domains listed in virtual_alias_domains, and valid users in
virtual_mailbox_maps.

Dang, mistyped...  Dovecot domains should be listed in
virtual_mailbox_domains, NOT virtual_alias_domains.



   -- Noel Jones



http://www.postfix.org/ADDRESS_CLASS_README.html




   -- Noel Jones


TY, Noel