[no subject]

[Андрей]

 lists

Re:

[wilfried.es...@essignetz.de]

Am 30.11.2015 um 10:31 schrieb Андрей:
>  lists
> 
Hi,

did you ever think about sending comands to majord...@postfix.org ?


Willi

Re:

[phil]

On 30/11/2015 8:33 PM, wilfried.es...@essignetz.de wrote:

Am 30.11.2015 um 10:31 schrieb Андрей:

  lists


Hi,

did you ever think about sending comands to majord...@postfix.org ?


Willi



Smells like a spammer to me, no subject, no body, 3 messages now all the 
same in the last 5 minutes, surely they can't be that inept with email.

Is there a list admin around . . . .

--
"Everything, always can be done otherwise and better."

Regards,
Phil

Fwd: more noise on the list

[phil]

On 30 Nov 2015, at 09:47, phil  wrote:


Smells like a spammer to me, no subject, no body, 3 messages now all the same 
in the last 5 minutes, surely they can't be that inept with email.


In that case, shut up! Don't add to the noise by posting to the list. 
This is not going to achieve anything apart from annoy even more people. 
Whoever is managing the list is not going to act any quicker because of 
your posting. He/she will have already seen the offending "spam" (if 
that's what it was) and take action in due course.

forward mail for a domain with its own certificate

[Evreh Choneh]

Hello

I want to do the following :

I've a domain A for all my users. For some users I have a domain B and I
would like to do this :

a) A user from domain B can send a mail only for another user of B
b) All mail from B use the certificate of domain B to crypt and sign mail

Can Postfix do that ? And how I can find documentation on that ?

Regards

Re: Duplicate email issue with opendkim milter

[Quanah Gibson-Mount]

--On Tuesday, November 24, 2015 12:42 AM + Viktor Dukhovni 
 wrote:




> Since this was implemented, we've had an issue where when emails with
> a  large number of recipients are processed, the result is that the
> recipients  get duplicates of the email.  We found one workaround to
> this was to  default_destination_recipient_limit to large value.

Why did that make a difference?


Well, of course I would change only "smtp-amavis_recipient_limit",
but the difference is that otherwise the default limit delivers at
most 50 recipients at a time to the content filter.  This reduces
opportunities for duplicate elimination (across lists), especially
with the default "enable_original_recipient = yes".

I've always (since ~2001) used large recipient limits with filter
transports, this also improves efficiency, no need to scan the same
content multiple times.


Hi Viktor,

Thanks for the reply!  I've been on vacation so catching up on email.  It 
sounds like the better solution then is to add:


-o default_destination_recipient_limit=5000

to the content filter definitions? ;)

--Quanah


--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration

Re: Feature: postqueue JSON output

[Wietse Venema]

Wietse Venema:
> This weekend I added preliminary support for JSON-formatted queue
> listings.  See below for a fragment from the postqueue manpage.
...
> I need to clean up the code and add quoting for control characters
> etc. before it can be released.

The code is released as postfix-3.1-20151129, with minor changes.
You can find the manpage at http://www.postfix.org/postqueue.1.html

The main change since the previous email is that the output is now
in the form of one JSON object per queue file, and that each object
is followed by newline to support simple streaming parsers.

A queue may contain millions of messages, and each message may have
a large number of recipients, therefore reading the entire output
into memory would not scale. Streaming parsers do not have that
problem.

So one object looks like:

{"queue_name": "active","queue_id": "xxx","arrival_time": 
1448908169,"message_size": 3359,"sender": "yyy","recipients": [{"address": 
"zzz"}]}

Recipients in the deferred queue may also have a "delay_reason"
member.

I see that there is some unnecessary whitespace. This does not
matter for JSON parsers, but I'll fix it anyway.

Wietse

Re: Duplicate email issue with opendkim milter

[Quanah Gibson-Mount]

--On Monday, November 30, 2015 7:00 AM -0800 Quanah Gibson-Mount 
 wrote:



I've always (since ~2001) used large recipient limits with filter
transports, this also improves efficiency, no need to scan the same
content multiple times.


Hi Viktor,

Thanks for the reply!  I've been on vacation so catching up on email.  It
sounds like the better solution then is to add:

-o default_destination_recipient_limit=5000

to the content filter definitions? ;)


I've tried variations on this with no success.  My master.cf eventually 
being the following, but still getting duplicates.  I added "-o 
receive_override_options=no_address_mappings" to the [127.0.0.1]:10030 
block, and after that, no more duplicates.  However, the original 
suggestion from Viktor still seems cleaner, although I'm not seeing it work 
so far. :/


smtp  inet  n   -   n   -   1   postscreen
tlsproxy  unix  -   -   n   -   0   tlsproxy
dnsblog   unix  -   -   n   -   0   dnsblog
smtpd pass  -   -   n   -   -   smtpd
   -o smtpd_tls_security_level=may
   -o content_filter=scan:[127.0.0.1]:10030
   -o default_destination_recipient_limit=100
465inet  n   -   n   -   -   smtpd
   -o content_filter=scan:[127.0.0.1]:10030
   -o default_destination_recipient_limit=100
   -o smtpd_tls_wrappermode=yes
   -o smtpd_sasl_auth_enable=yes
   -o smtpd_client_restrictions=
   -o smtpd_data_restrictions=
   -o smtpd_helo_restrictions=
   -o smtpd_recipient_restrictions=
   -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
   -o syslog_name=postfix/smtps
   -o milter_macro_daemon_name=ORIGINATING
submission inet n  -   n   -   -   smtpd
   -o content_filter=scan:[127.0.0.1]:10030
   -o default_destination_recipient_limit=100
   -o smtpd_etrn_restrictions=reject
   -o smtpd_sasl_auth_enable=yes
   -o smtpd_tls_security_level=may
   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
   -o smtpd_data_restrictions=
   -o smtpd_helo_restrictions=
   -o smtpd_recipient_restrictions=
   -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
   -o syslog_name=postfix/submission
   -o milter_macro_daemon_name=ORIGINATING
scan  unix  -   -   n   -   10  smtp
   -o smtp_send_xforward_command=yes
   -o disable_mime_output_conversion=yes
   -o smtp_generic_maps=
pickupunix  n   -   n   60  1   pickup
cleanup   unix  n   -   n   -   0   cleanup
qmgr  unix  n   -   n   300 1   qmgr
tlsmgrunix  -   -   n   1000?   1   tlsmgr
rewrite   unix  -   -   n   -   -   trivial-rewrite
bounceunix  -   -   n   -   0   bounce
defer unix  -   -   n   -   0   bounce
trace unix  -   -   n   -   0   bounce
verifyunix  -   -   n   -   1   verify
flush unix  n   -   n   1000?   0   flush
proxymap  unix  -   -   n   -   -   proxymap
smtp  unix  -   -   n   -   -   smtp
relay unix  -   -   n   -   -   smtp
showq unix  n   -   n   -   -   showq
error unix  -   -   n   -   -   error
retry unix  -   -   n   -   -   error
discard   unix  -   -   n   -   -   discard
local unix  -   n   n   -   -   local
virtual   unix  -   n   n   -   -   virtual
lmtp  unix  -   -   n   -   -   lmtp
anvil unix  -   -   n   -   1   anvil
scacheunix  -   -   n   -   1   scache
maildrop  unix  -   n   n   -   -   pipe
 flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
old-cyrus unix  -   n   n   -   -   pipe
 flags=R user=cyrus argv=/cyrus/bin/deliver -e -m ${extension} ${user}
cyrus unix  -   n   n   -   -   pipe
 user=cyrus argv=/cyrus/bin/deliver -e -r ${sender} -m ${extension} ${user}
uucp  unix  -   n   n   -   -   pipe
 flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail 
($recipient)

ifmailunix  -   n   n   -   -   pipe
 flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp unix  -   n   n   -   -   pipe
 flags=Fq. user=foo argv=/usr/local/sbin/bsmtp -f $sender $nexthop 
$recipient

smtp-amavis unix -  -   n   -   10  smtp
   -o smtp_data_done_timeout=1200
   -o smtp_send_xforward_command=yes
   -o disable_dns_lookups=yes
   -o default_destination_recipient_limit=100
   -o max_use=20
[127.0.0.1]:10025 inet n  -   n   -   -  smtpd
   -o content_filter=
   -o default_destination_recipient_limit=100
   -o 

Re: Duplicate email issue with opendkim milter

[Quanah Gibson-Mount]

--On Monday, November 30, 2015 3:01 PM -0800 Quanah Gibson-Mount 
 wrote:



--On Monday, November 30, 2015 2:56 PM -0800 Quanah Gibson-Mount
 wrote:


--On Monday, November 30, 2015 7:00 AM -0800 Quanah Gibson-Mount
 wrote:


I've always (since ~2001) used large recipient limits with filter
transports, this also improves efficiency, no need to scan the same
content multiple times.


Hi Viktor,

Thanks for the reply!  I've been on vacation so catching up on email.
It sounds like the better solution then is to add:

-o default_destination_recipient_limit=5000

to the content filter definitions? ;)


I've tried variations on this with no success.  My master.cf eventually
being the following, but still getting duplicates.  I added "-o
receive_override_options=no_address_mappings" to the [127.0.0.1]:10030
block, and after that, no more duplicates.  However, the original
suggestion from Viktor still seems cleaner, although I'm not seeing it
work so far. :/


I also set:

smtp-amavis_destination_recipient_limit = 100

via postconf, with no change in behavior.

Either default_destination_recipient_limit has to be bumped up via
postconf, or -o receive_override_options=no_address_mappings requires
setting to resolve this so far.


and for completion, setting:

smtp-amavis_recipient_limit = 100

had no change in behavior either. ;)

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration

Re: Duplicate email issue with opendkim milter

[Viktor Dukhovni]

On Mon, Nov 30, 2015 at 07:00:08AM -0800, Quanah Gibson-Mount wrote:

> >I've always (since ~2001) used large recipient limits with filter
> >transports, this also improves efficiency, no need to scan the same
> >content multiple times.
> 
> Hi Viktor,
> 
> Thanks for the reply!  I've been on vacation so catching up on email.  It
> sounds like the better solution then is to add:
> 
> -o default_destination_recipient_limit=5000
> 
> to the content filter definitions? ;)

That won't work.  The recipient limits are used in queue manager,
not the transport.

_destination_recipient_limit

And this would be an unwise global default, and the number is much
too high.  You get dimishing returns especially beyond whatever
you've set for the virtual expansion limits.

-- 
Viktor.

Re: Duplicate email issue with opendkim milter

[Quanah Gibson-Mount]

--On Tuesday, December 01, 2015 12:03 AM + Viktor Dukhovni 
 wrote:



On Mon, Nov 30, 2015 at 03:11:39PM -0800, Quanah Gibson-Mount wrote:


--On Monday, November 30, 2015 3:08 PM -0800 Quanah Gibson-Mount
 wrote:

>> Either default_destination_recipient_limit has to be bumped up via
>> postconf, or -o receive_override_options=no_address_mappings requires
>> setting to resolve this so far.

Hm, so according to our clients setting
default_destination_recipient_limit to a size larger than the list size
fixed the issue for them.  However, I just tested that as well, and it
had no effect either.  So really, the only way that I stop seeing
duplicates is to set -o
receive_override_options=no_address_mappings


The main effect of higher recipient limits is to reduce the CPU
cost of processing multiple copies of the same message.  Any effect
on duplicate suppression is largely coincidental.

Duplicates arise when multiple lists have common recipients, and
whether these lead to multiple deliveries or not depends mostly on
enable_original_recipient.


That's not really what we're seeing.  What we are seeing is:

A list has 51 or more members (users1 through users55)

One of those list members sets their email to forward somewhere else (local 
or remote, doesn't matter) (say, user50 forwards to user70).


The user who has a forward set will receive two copies of the email at 
their forward location unless no_address_mappings is specified.


--Quanah


--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration

Re: Duplicate email issue with opendkim milter

[Viktor Dukhovni]

On Mon, Nov 30, 2015 at 04:11:15PM -0800, Quanah Gibson-Mount wrote:

> >Duplicates arise when multiple lists have common recipients, and
> >whether these lead to multiple deliveries or not depends mostly on
> >enable_original_recipient.
> 
> That's not really what we're seeing.  What we are seeing is:
> 
> A list has 51 or more members (users1 through users55)
> 
> One of those list members sets their email to forward somewhere else (local
> or remote, doesn't matter) (say, user50 forwards to user70).

That is two lists with common members, one list is user50 (expands
to user70), the other list is user70 (no expansion).  Your real
problem however is the self-referencing user50:

user50: user70, user50

If you expand this twice, you get:

user50 -> user70, user50 > user70, user50
\
 > user70

Hence the duplication.  At the second hop, the two expansions have
different original recipient values.  This is why FILTER_README
describes doing virtual expansion either before or after the filter,
but not both.

I usually solve this differently.  I avoid self-referential
expansions!

virtual:
use...@example.com  
use...@mailstore-name.example.com,
use...@mailstore-name.example.com,

That is, I ensured that the input keys for virtual aliases are
*always* in virtual alias domains (this is not required, but a good
idea).  And the outputs are *never* in virtual alias domains.  I
used LDAP with a "domain = example.com" setting to not even bother
to do lookups on the output domains (big latency saving since
virtual alias expansion is recursive).

I had an environment with multiple mailstores under a single virtual
domain.  Multiple Microsoft Exchange deployments, some IMAP
mailstores, and some cloud mailstores.  All expansions were:

mail -> maildrop

not

mail -> mail

The domainpart of "mail" was always a virtual alias domain.  The
domainpart of "maildrop" is always the routing information to the
user's mailstore.  The transport table was per maildrop domain,
not per user.

-- 
Viktor.

Re: Duplicate email issue with opendkim milter

[Quanah Gibson-Mount]

--On Monday, November 30, 2015 3:08 PM -0800 Quanah Gibson-Mount 
 wrote:



Either default_destination_recipient_limit has to be bumped up via
postconf, or -o receive_override_options=no_address_mappings requires
setting to resolve this so far.


Hm, so according to our clients setting default_destination_recipient_limit 
to a size larger than the list size fixed the issue for them.  However, I 
just tested that as well, and it had no effect either.  So really, the only 
way that I stop seeing duplicates is to set -o 
receive_override_options=no_address_mappings


--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration

Re: Duplicate email issue with opendkim milter

[Quanah Gibson-Mount]

--On Monday, November 30, 2015 2:56 PM -0800 Quanah Gibson-Mount 
 wrote:



--On Monday, November 30, 2015 7:00 AM -0800 Quanah Gibson-Mount
 wrote:


I've always (since ~2001) used large recipient limits with filter
transports, this also improves efficiency, no need to scan the same
content multiple times.


Hi Viktor,

Thanks for the reply!  I've been on vacation so catching up on email.  It
sounds like the better solution then is to add:

-o default_destination_recipient_limit=5000

to the content filter definitions? ;)


I've tried variations on this with no success.  My master.cf eventually
being the following, but still getting duplicates.  I added "-o
receive_override_options=no_address_mappings" to the [127.0.0.1]:10030
block, and after that, no more duplicates.  However, the original
suggestion from Viktor still seems cleaner, although I'm not seeing it
work so far. :/


I also set:

smtp-amavis_destination_recipient_limit = 100

via postconf, with no change in behavior.

Either default_destination_recipient_limit has to be bumped up via 
postconf, or -o receive_override_options=no_address_mappings requires 
setting to resolve this so far.


--Quanah


--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration

Re: Duplicate email issue with opendkim milter

[Viktor Dukhovni]

On Mon, Nov 30, 2015 at 03:11:39PM -0800, Quanah Gibson-Mount wrote:

> --On Monday, November 30, 2015 3:08 PM -0800 Quanah Gibson-Mount
>  wrote:
> 
> >>Either default_destination_recipient_limit has to be bumped up via
> >>postconf, or -o receive_override_options=no_address_mappings requires
> >>setting to resolve this so far.
> 
> Hm, so according to our clients setting default_destination_recipient_limit
> to a size larger than the list size fixed the issue for them.  However, I
> just tested that as well, and it had no effect either.  So really, the only
> way that I stop seeing duplicates is to set -o
> receive_override_options=no_address_mappings

The main effect of higher recipient limits is to reduce the CPU
cost of processing multiple copies of the same message.  Any effect
on duplicate suppression is largely coincidental.

Duplicates arise when multiple lists have common recipients, and
whether these lead to multiple deliveries or not depends mostly on
enable_original_recipient.

-- 
Viktor.

Re: Blocking Nessus Scans

[Sven Schwedas]

On 2015-11-30 14:14, Daniel Bray wrote:
> I've tried to configure the
> reject_unauth_destination and permit_sasl_authenticated for both
> smtpd_relay_restrictions and smtpd_recipient_restrictions, but the
> cleanup appears to still be taking over, and converting this into a
> legit email bound for nobody.

How exactly? smtpd_relay_restrictions is parsed in order, so if you set
up like above:

> smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, 
> reject_unauth_destination

, as long as 10.10.10.10 is in $mynetworks, all other checks are
skipped. Put permit_mynetworks at the end (or drop it entirely, if
feasible).

> 
> Any suggestions on how to completely drop these types messages?
> 
> Thanks,
> -DB
> 

-- 
Mit freundlichen Grüßen, / Best Regards,
Sven Schwedas
Systemadministrator
TAO Beratungs- und Management GmbH | Lendplatz 45 | A - 8020 Graz
Mail/XMPP: sven.schwe...@tao.at | +43 (0)680 301 7167
http://software.tao.at



signature.asc
Description: OpenPGP digital signature

Re: Blocking Nessus Scans

[Wietse Venema]

Daniel Bray:
> Any suggestions on how to completely drop these types messages?

http://www.postfix.org/postconf.5.html#notify_classes

Wietse

[no subject]

[Андрей]

 lists

[no subject]

[Андрей]

 lists

Blocking Nessus Scans

[Daniel Bray]

Hello list,

Our external pen testers are performing a specific type of scan on our
email servers, and it's generating a bit of spam. I'm trying to find a way
to block these messages, while still allowing the team to scan (meaning, I
can't just use iptables and block them). I have the following settings in
place:

mydestination = $myhostname, localhost.$mydomain, localhost
unknown_local_recipient_reject_code = 550
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
debug_peer_level = 2
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_sasl_path = sasl2/smtpd.conf
smtpd_sasl_security_options = noanonymous
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_unauth_destination
smtpd_tls_auth_only = no
smtp_use_tls = yes
smtpd_use_tls = yes
smtp_tls_note_starttls_offer = yes
smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key
smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt
smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_protocols = !SSLv2, !SSLv3
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
smtp_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK,
aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDB3-SHA, KRB5-DES, CBC3-SHA
smtpd_tls_dh1024_param_file = /etc/postfix/ssl/dhparams.pem
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination
smtp_generic_maps = hash:/etc/postfix/generic

Here is the log entry of the scanner sending its "ping" scan:
Nov 17 05:09:02 testserver postfix/smtpd[5764]: connect from
unknown[10.10.10.10]
Nov 17 05:09:02 testserver postfix/smtpd[5764]: warning:
network_biopair_interop: error reading 5 bytes from the network: Connection
reset by peer
Nov 17 05:09:02 testserver postfix/smtpd[5764]: SSL_accept error from
unknown[10.10.10.10]: -1
Nov 17 05:09:02 testserver postfix/smtpd[5764]: lost connection after
STARTTLS from unknown[10.10.10.10]
Nov 17 05:09:02 testserver postfix/smtpd[5764]: disconnect from
unknown[10.10.10.10]
Nov 17 05:09:02 testserver postfix/cleanup[5766]: 9993E40397: message-id=()
{ :;}; ping -p 074f5a50596c656c794f5a -c 3 scan02
Nov 17 05:09:02 testserver postfix/local[5767]: 817C0402AC: to=<
nob...@testserver.com>,
orig_to=, relay=local, delay=0.14, delays=0.07/0.06/0/0.01,
dsn=2.0.0, status=sent (forwarded as 9993E40397)


>From there, it goes to "nobody" which goes to "root" who has a .forward to
send it to the internal group. I've contacted our external pen testers, and
they tell me it's just a "normal Nessus smtp scan, which tries to send
commands". I've tried to configure the reject_unauth_destination and
permit_sasl_authenticated for both smtpd_relay_restrictions and
smtpd_recipient_restrictions, but the cleanup appears to still be taking
over, and converting this into a legit email bound for nobody.

Any suggestions on how to completely drop these types messages?

Thanks,
-DB

Re: Blocking Nessus Scans

[Fernando Maior]

Hi,

May be you should not relay messages for "nobody" to "root"... How are you
doing this relaying? If you are using aliases, just delete the line
"nobody: root" and rerun postconf. It will be delivered locally, so you can
gain access to the emails. But it will not be delivered to root and
forwarded to the internal group, and that I think is what you want...

Cheers!

Atenciosamente,
---
Fernando Maciel Souto Maior
Projetos e Soluções de Tecnologia
(31) 99226-9440 TIM

On Mon, Nov 30, 2015 at 12:11 PM, Wietse Venema 
wrote:

> Daniel Bray:
> > Any suggestions on how to completely drop these types messages?
>
> http://www.postfix.org/postconf.5.html#notify_classes
>
> Wietse
>