Re: Reject unknown users, even when sent from 'mydomain'

[durwin]

owner-postfix-us...@postfix.org wrote on 07/02/2018 09:58:57 AM:

> From: Noel Jones 
> To: postfix-users@postfix.org
> Date: 07/02/2018 09:59 AM
> Subject: Re: Reject unknown users, even when sent from 'mydomain'
> Sent by: owner-postfix-us...@postfix.org
> 
> On 7/2/2018 10:20 AM, dur...@mgtsciences.com wrote:
> > If my postfix server is 172.23.93.188, and my Domino server is
> > 172.23.93.10.
> > The router forwards all mail to 188.  The postfix server must send
> > it to 10
> > for delivery.  What is needed to allow this 'relaying' from 188 to
> > 10 without
> > becoming an open relay?
> > 
> > Durwin
> > 
> 
> This is what we refer to as an email firewall or gateway.
> 
> A basic, annotated example of this can be found here:
> http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall
> 
> The key parts are that the internal domain should be listed in
> relay_domains (not mydestination), and valid recipients should be
> listed in relay_recipient_maps.

I guess I still got it wrong.  I looked closer at what you said about
relay_domain.  I will try that.

Thank you.
> 
> It's also possible for postfix to build a list of valid recipients
> automatically *if* the internal server rejects unknown recipients
> during the SMTP transaction.
> 
> Other relevant links:
> http://www.postfix.org/ADDRESS_CLASS_README.html
> http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient
> http://www.postfix.org/documentation.html
> 
> 
> 
>   -- Noel Jones



This email message and any attachments are for the sole use of the 
intended recipient(s) and may contain proprietary and/or confidential 
information which may be privileged or otherwise protected from 
disclosure. Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient(s), please contact the 
sender by reply email and destroy the original message and any copies of 
the message as well as any attachments to the original message.

Re: Reject unknown users, even when sent from 'mydomain'

[Noel Jones]

On 7/2/2018 10:20 AM, dur...@mgtsciences.com wrote:
> If my postfix server is 172.23.93.188, and my Domino server is
> 172.23.93.10.
> The router forwards all mail to 188.  The postfix server must send
> it to 10
> for delivery.  What is needed to allow this 'relaying' from 188 to
> 10 without
> becoming an open relay?
> 
> Durwin
> 

This is what we refer to as an email firewall or gateway.

A basic, annotated example of this can be found here:
http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall

The key parts are that the internal domain should be listed in
relay_domains (not mydestination), and valid recipients should be
listed in relay_recipient_maps.

It's also possible for postfix to build a list of valid recipients
automatically *if* the internal server rejects unknown recipients
during the SMTP transaction.

Other relevant links:
http://www.postfix.org/ADDRESS_CLASS_README.html
http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient
http://www.postfix.org/documentation.html



  -- Noel Jones

Re: Reject unknown users, even when sent from 'mydomain'

[durwin]

owner-postfix-us...@postfix.org wrote on 07/02/2018 09:14:06 AM:

> From: Wietse Venema 
> To: Postfix users 
> Date: 07/02/2018 09:14 AM
> Subject: Re: Reject unknown users, even when sent from 'mydomain'
> Sent by: owner-postfix-us...@postfix.org
> 
> dur...@mgtsciences.com:
> > I have smtpd_authorized_xclient_hosts defined.  I then used this.
> > 
> > EHLO 
> > XCLIENT NAME= ADDR=
> > EHLO 
> > MAIL FROM:
> > RCPT TO:
> > 
> > I get 'Relay access denied'.  However, I am not trying to relay, I am 
> > trying
> > to deliver *to* this postfix server.  'Mydomain' *is* this server. 
Does 
> > it
> > make a difference that it is to forward to another server (Domino) in 
same 
> > LAN?
> 
> Mail is not delivered to this server.
> 
> Mail is forwarded to another server.
> 
> That *IS* the definition of relaying.
> 
>Wietse

If my postfix server is 172.23.93.188, and my Domino server is 
172.23.93.10.
The router forwards all mail to 188.  The postfix server must send it to 
10
for delivery.  What is needed to allow this 'relaying' from 188 to 10 
without
becoming an open relay?

Durwin


This email message and any attachments are for the sole use of the 
intended recipient(s) and may contain proprietary and/or confidential 
information which may be privileged or otherwise protected from 
disclosure. Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient(s), please contact the 
sender by reply email and destroy the original message and any copies of 
the message as well as any attachments to the original message.

Re: Reject unknown users, even when sent from 'mydomain'

[Wietse Venema]

dur...@mgtsciences.com:
> I have smtpd_authorized_xclient_hosts defined.  I then used this.
> 
> EHLO 
> XCLIENT NAME= ADDR=
> EHLO 
> MAIL FROM:
> RCPT TO:
> 
> I get 'Relay access denied'.  However, I am not trying to relay, I am 
> trying
> to deliver *to* this postfix server.  'Mydomain' *is* this server.  Does 
> it
> make a difference that it is to forward to another server (Domino) in same 
> LAN?

Mail is not delivered to this server.

Mail is forwarded to another server.

That *IS* the definition of relaying.

Wietse

Re: Reject unknown users, even when sent from 'mydomain'

[durwin]

owner-postfix-us...@postfix.org wrote on 07/02/2018 07:59:35 AM:

> From: Matus UHLAR - fantomas 
> To: postfix-users@postfix.org, owner-postfix-us...@postfix.org
> Date: 07/02/2018 08:00 AM
> Subject: Re: Reject unknown users, even when sent from 'mydomain'
> Sent by: owner-postfix-us...@postfix.org
> 
> >owner-postfix-us...@postfix.org wrote on 06/29/2018 09:12:34 PM:
> >
> >> From: "Bill Cole" 
> >> To: "Postfix users" 
> >> Date: 06/29/2018 09:13 PM
> >> Subject: Re: Reject unknown users, even when sent from 'mydomain'
> >> Sent by: owner-postfix-us...@postfix.org
> >>
> >> On 29 Jun 2018, at 16:55 (-0400), dur...@mgtsciences.com wrote:
> >>
> >> > Still delivers unknown user.  I've attached the main.cf and the 
log.
> >>
> >> For future reference: please read the last section of the Postfix
> >> DEBUG_README file and note that it does not recommend debug-level
> >> logging or whole main.cf files.
> >>
> >> But the reason your test permitted you to submit a message to a bogus
> >> user is obvious despite the clutter: when  'permit_mynetworks' occurs
> >> first in a restriction list, connections from IPs in $mynetworks are
> >> exempted from all other restrictions in that list.
> 
> On 02.07.18 07:52, dur...@mgtsciences.com wrote:
> >Thank you.  I agree, it it is obvious.  I has looking for a bigger 
problem
> >when is was a small one.
> >
> >Could I expect xclient to work for testing?  If so, does the NAME and 
ADDR
> >need to be resolvable? Can I define them to be anything except my LAN?
> >
> >XCLIENT NAME= ADDR=
> 
> configure smtpd_authorized_xclient_hosts
> 
> http://www.postfix.org/postconf.5.html#smtpd_authorized_xclient_hosts

I have smtpd_authorized_xclient_hosts defined.  I then used this.

EHLO 
XCLIENT NAME= ADDR=
EHLO 
MAIL FROM:
RCPT TO:

I get 'Relay access denied'.  However, I am not trying to relay, I am 
trying
to deliver *to* this postfix server.  'Mydomain' *is* this server.  Does 
it
make a difference that it is to forward to another server (Domino) in same 
LAN?


> 
> 
> 
> -- 
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> "Where do you want to go to die?" [Microsoft]



This email message and any attachments are for the sole use of the 
intended recipient(s) and may contain proprietary and/or confidential 
information which may be privileged or otherwise protected from 
disclosure. Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient(s), please contact the 
sender by reply email and destroy the original message and any copies of 
the message as well as any attachments to the original message.

Re: Reject unknown users, even when sent from 'mydomain'

[Matus UHLAR - fantomas]

owner-postfix-us...@postfix.org wrote on 06/29/2018 09:12:34 PM:


From: "Bill Cole" 
To: "Postfix users" 
Date: 06/29/2018 09:13 PM
Subject: Re: Reject unknown users, even when sent from 'mydomain'
Sent by: owner-postfix-us...@postfix.org

On 29 Jun 2018, at 16:55 (-0400), dur...@mgtsciences.com wrote:

> Still delivers unknown user.  I've attached the main.cf and the log.

For future reference: please read the last section of the Postfix
DEBUG_README file and note that it does not recommend debug-level
logging or whole main.cf files.

But the reason your test permitted you to submit a message to a bogus
user is obvious despite the clutter: when  'permit_mynetworks' occurs
first in a restriction list, connections from IPs in $mynetworks are
exempted from all other restrictions in that list.


On 02.07.18 07:52, dur...@mgtsciences.com wrote:

Thank you.  I agree, it it is obvious.  I has looking for a bigger problem
when is was a small one.

Could I expect xclient to work for testing?  If so, does the NAME and ADDR
need to be resolvable? Can I define them to be anything except my LAN?

XCLIENT NAME= ADDR=


configure smtpd_authorized_xclient_hosts

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



--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"Where do you want to go to die?" [Microsoft]

Re: Reject unknown users, even when sent from 'mydomain'

[durwin]

owner-postfix-us...@postfix.org wrote on 06/29/2018 09:12:34 PM:

> From: "Bill Cole" 
> To: "Postfix users" 
> Date: 06/29/2018 09:13 PM
> Subject: Re: Reject unknown users, even when sent from 'mydomain'
> Sent by: owner-postfix-us...@postfix.org
> 
> On 29 Jun 2018, at 16:55 (-0400), dur...@mgtsciences.com wrote:
> 
> > Still delivers unknown user.  I've attached the main.cf and the log.
> 
> For future reference: please read the last section of the Postfix 
> DEBUG_README file and note that it does not recommend debug-level 
> logging or whole main.cf files.
> 
> But the reason your test permitted you to submit a message to a bogus 
> user is obvious despite the clutter: when  'permit_mynetworks' occurs 
> first in a restriction list, connections from IPs in $mynetworks are 
> exempted from all other restrictions in that list.

Thank you.  I agree, it it is obvious.  I has looking for a bigger problem
when is was a small one.

Could I expect xclient to work for testing?  If so, does the NAME and ADDR
need to be resolvable? Can I define them to be anything except my LAN?

XCLIENT NAME= ADDR=

> 
> 
> -- 
> Bill Cole
> b...@scconsult.com or billc...@apache.org
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Currently Seeking Steadier Work: https://linkedin.com/in/billcole



This email message and any attachments are for the sole use of the 
intended recipient(s) and may contain proprietary and/or confidential 
information which may be privileged or otherwise protected from 
disclosure. Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient(s), please contact the 
sender by reply email and destroy the original message and any copies of 
the message as well as any attachments to the original message.

Re: Reject unknown users, even when sent from 'mydomain'

[Bill Cole]

On 29 Jun 2018, at 16:55 (-0400), dur...@mgtsciences.com wrote:


Still delivers unknown user.  I've attached the main.cf and the log.


For future reference: please read the last section of the Postfix 
DEBUG_README file and note that it does not recommend debug-level 
logging or whole main.cf files.


But the reason your test permitted you to submit a message to a bogus 
user is obvious despite the clutter: when  'permit_mynetworks' occurs 
first in a restriction list, connections from IPs in $mynetworks are 
exempted from all other restrictions in that list.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steadier Work: https://linkedin.com/in/billcole

Re: Reject unknown users, even when sent from 'mydomain'

[durwin]

Still delivers unknown user.  I've attached the main.cf and the log.

@Matus
Thank you for suggesting msmtp.  It is handy.  As for the text server 
appends to all outgoing email, it is impractical to disable it for each 
email going to a list, sorry. :)




Durwin F. De La Rue
Management Sciences, Inc.
6022 Constitution Ave. NE
Albuquerque, NM  87110
Phone (505) 255-8611



From:   "Bill Cole" 
To: "Postfix users" 
Date:   06/28/2018 05:41 PM
Subject:    Re: Reject unknown users, even when sent from 'mydomain'
Sent by:owner-postfix-us...@postfix.org



On 28 Jun 2018, at 15:35, dur...@mgtsciences.com wrote:

> I have a LAN behind a firewall with port 25 forwarded to machine 
> running
> postfix.  That machine sends email on to
> a Domino server.  However, I am using a VM for testing and I cannot 
> change
> the forwarded port.  So I am doing it
> all from the postfix machine.  I use the command below to send an 
> email to
> an unknown user (from command line).
> But it delivers it to Domino anyway.  I have only one user defined in
> /etc/postfix/aliases file.  Do I have the right
> configuration to reject unknown users?

No.

> If not, what am I missing?

smtpd_recipient_restrictions and/or smtpd_relay_restrictions.

See the postconf(5) man page, the SMTPD_ACCESS_README file, and the 
ADDRESS_VERIFICATION_README file for the mechanisms available for 
determining whether a specific recipient address in a relay domain is 
valid. For your circumstance you probably need to use recipient 
verification but if Domino provides an LDAP interface that could also be 
an option.







This email message and any attachments are for the sole use of the 
intended recipient(s) and may contain proprietary and/or confidential 
information which may be privileged or otherwise protected from 
disclosure. Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient(s), please contact the 
sender by reply email and destroy the original message and any copies of 
the message as well as any attachments to the original message.

log
Description: Binary data


main.cf
Description: Binary data

Re: Reject unknown users, even when sent from 'mydomain'

[Matus UHLAR - fantomas]

On 28.06.18 13:35, dur...@mgtsciences.com wrote:

=== command ===
cat email.txt | nc postfix 25
=== end ===


does this work? you should use SMTP client like 'msmtp' instead.
(you can configure authentication and encryption with it).


This email message and any attachments are for the sole use of the
intended recipient(s) and may contain proprietary and/or confidential
information which may be privileged or otherwise protected from
disclosure. Any unauthorized review, use, disclosure or distribution is
prohibited. If you are not the intended recipient(s), please contact the
sender by reply email and destroy the original message and any copies of
the message as well as any attachments to the original message.


funny for a list mail.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"The box said 'Requires Windows 95 or better', so I bought a Macintosh".

Re: Reject unknown users, even when sent from 'mydomain'

[Bill Cole]

On 28 Jun 2018, at 15:35, dur...@mgtsciences.com wrote:

I have a LAN behind a firewall with port 25 forwarded to machine 
running

postfix.  That machine sends email on to
a Domino server.  However, I am using a VM for testing and I cannot 
change

the forwarded port.  So I am doing it
all from the postfix machine.  I use the command below to send an 
email to

an unknown user (from command line).
But it delivers it to Domino anyway.  I have only one user defined in
/etc/postfix/aliases file.  Do I have the right
configuration to reject unknown users?


No.


If not, what am I missing?


smtpd_recipient_restrictions and/or smtpd_relay_restrictions.

See the postconf(5) man page, the SMTPD_ACCESS_README file, and the 
ADDRESS_VERIFICATION_README file for the mechanisms available for 
determining whether a specific recipient address in a relay domain is 
valid. For your circumstance you probably need to use recipient 
verification but if Domino provides an LDAP interface that could also be 
an option.

Reject unknown users, even when sent from 'mydomain'

[durwin]

I have a LAN behind a firewall with port 25 forwarded to machine running 
postfix.  That machine sends email on to
a Domino server.  However, I am using a VM for testing and I cannot change 
the forwarded port.  So I am doing it
all from the postfix machine.  I use the command below to send an email to 
an unknown user (from command line).
But it delivers it to Domino anyway.  I have only one user defined in 
/etc/postfix/aliases file.  Do I have the right
configuration to reject unknown users?  If not, what am I missing?

Thank you,

Durwin

=== command ===
cat email.txt | nc postfix 25
=== end ===

=== email.txt ===
helo postfix.mydomain.com
mail from: u...@mydomain.com
rcpt to: unknownu...@mydomain.com
data
From: u...@mydomain.com
To: unknownu...@mydomain.com
Subject: Test
Test
.
quit
=== end email.txt ===


=== main.cf ===
compatibility_level = 2
queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
mail_owner = postfix
myhostname = postfix.mydomain.com
mydomain = mydomain.com
myorigin = $myhostname
inet_interfaces = all
inet_protocols = all
mydestination = $myhostname, localhost.$mydomain, localhost
local_recipient_maps = $alias_maps
unknown_local_recipient_reject_code = 550
mynetworks = 172.23.93.0/24
relay_domains = $mydestination
relayhost = $mydomain
alias_maps = hash:/etc/postfix/aliases
alias_database = hash:/etc/aliases


smtpd_banner = $myhostname ESMTP $mail_name ($mail_version)
debug_peer_level = 2
debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
ddd $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/sbin/sendmail.postfix
newaliases_path = /usr/bin/newaliases.postfix
mailq_path = /usr/bin/mailq.postfix
setgid_group = postdrop
html_directory = no
manpage_directory = /usr/share/man
sample_directory = /usr/share/doc/postfix/samples
readme_directory = /usr/share/doc/postfix/README_FILES
meta_directory = /etc/postfix
shlib_directory = /usr/lib64/postfix
=== end main.cf ===


This email message and any attachments are for the sole use of the 
intended recipient(s) and may contain proprietary and/or confidential 
information which may be privileged or otherwise protected from 
disclosure. Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient(s), please contact the 
sender by reply email and destroy the original message and any copies of 
the message as well as any attachments to the original message.

Re: how to black hole unknown users on a server that acts as a mailing list

[cmc]

Thanks for the reply

> On Thu, Dec 08, 2016 at 02:58:24PM +, cmc wrote:
>> We have a server running Postfix, with mailing lists run by
>> Mailman, for a local domain. This server receives mail from an
>> upstream cloud-based server for all recipients not on the
>> cloud-based server (the idea being that any user not on the cloud
>> server is a mailing list).
>
> Ouch.  Ugly and wrong.

Yes, it is not ideal. The longer term aim is to migrate the mailing-lists
to the cloud server, then this horrible mess can go away...

>
>> The mail is relayed to the mailing list
>> server via another internal postfix server. Mail that is sent to
>> users that don't exists and are not mailing lists ends up on the
>> relay server, as it gets rejected with 'user unknown' by the
>> mailing list server when Postfix sees that it is not in the
>> local_recipient_maps. This ends up clogging up the relay server as
>> it tried to deliver (mostly spam) back to the originators. I think
>> the best solution may be to have the mailing list server to accept
>> mail received via SMTP that it doesn't have a local_recipient_map
>> for, and then forward it to /dev/null, but I'm not quite sure how
>> to do this. Or perhaps there is a way on the relay server to delete
>> mail it gets a 550 unknown response for.
>>
>> Any suggestions as to the best way to do this?
>
> Both the frontend (MX host) and the backend (Mailman host) need to
> have complete address lists for the domain (or domains) involved.
> Then transport_maps on each host should route the mail for the
> other host's addresses to that host.
>
> It's easy enough to replicate the Mailman aliases to the MX host, but
> replicating the MX host's address list to the internal Mailman host
> might be more of a problem.  (Or it might not ... we don't know how
> you configured it.)

The MX host doesn't really have any users of its own (except for the usual
candidates, such as root). I will check on the ease/possibility of replicating
from the cloud host (Gmail) to both those servers.
>
> Anyway, there it is, that's what you have to do.

Cheers,

-C

> --
>   http://rob0.nodns4.us/
>   Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: how to black hole unknown users on a server that acts as a mailing list

[/dev/rob0]

On Thu, Dec 08, 2016 at 02:58:24PM +, cmc wrote:
> We have a server running Postfix, with mailing lists run by 
> Mailman, for a local domain. This server receives mail from an 
> upstream cloud-based server for all recipients not on the 
> cloud-based server (the idea being that any user not on the cloud 
> server is a mailing list).

Ouch.  Ugly and wrong.

> The mail is relayed to the mailing list 
> server via another internal postfix server. Mail that is sent to 
> users that don't exists and are not mailing lists ends up on the 
> relay server, as it gets rejected with 'user unknown' by the 
> mailing list server when Postfix sees that it is not in the 
> local_recipient_maps. This ends up clogging up the relay server as 
> it tried to deliver (mostly spam) back to the originators. I think 
> the best solution may be to have the mailing list server to accept 
> mail received via SMTP that it doesn't have a local_recipient_map 
> for, and then forward it to /dev/null, but I'm not quite sure how 
> to do this. Or perhaps there is a way on the relay server to delete 
> mail it gets a 550 unknown response for.
> 
> Any suggestions as to the best way to do this?

Both the frontend (MX host) and the backend (Mailman host) need to 
have complete address lists for the domain (or domains) involved.
Then transport_maps on each host should route the mail for the 
other host's addresses to that host.

It's easy enough to replicate the Mailman aliases to the MX host, but 
replicating the MX host's address list to the internal Mailman host 
might be more of a problem.  (Or it might not ... we don't know how 
you configured it.)

Anyway, there it is, that's what you have to do.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

how to black hole unknown users on a server that acts as a mailing list

[cmc]

Hi,

We have a server running Postfix, with mailing lists run by Mailman,
for a local domain. This server receives mail from an upstream
cloud-based server for all recipients not on the cloud-based server
(the idea being that any user not on the cloud server is a mailing
list). The mail is relayed to the mailing list server via another
internal postfix server. Mail that is sent to users that don't exists
and are not mailing lists ends up on the relay server, as it gets
rejected with 'user unknown' by the mailing list server when Postfix
sees that it is not in the local_recipient_maps. This ends up clogging
up the relay server as it tried to deliver (mostly spam) back to the
originators. I think the best solution may be to have the mailing list
server to accept mail received via SMTP that it doesn't have a
local_recipient_map for, and then forward it to /dev/null, but I'm not
quite sure how to do this. Or perhaps there is a way on the relay
server to delete mail it gets a 550 unknown response for.

Any suggestions as to the best way to do this?

Thanks,

Cam

Re: postfix/smtpd connections from unknown users. Dealing with same?

[Robert Chalmers]

Yes, I am using postscreen.

So I’m presuming that’s enough.

postconf -n | grep postscreen

postscreen_access_list = permit_mynetworks, 
cidr:/usr/local/etc/postfix/postscreen_access.cidr, 
cidr:/usr/local/etc/postfix/postscreen_spf_whitelist.cidr
postscreen_bare_newline_action = enforce
postscreen_bare_newline_enable = yes
postscreen_bare_newline_ttl = 30d
postscreen_blacklist_action = drop
postscreen_cache_cleanup_interval = 12h
postscreen_cache_map = btree:$data_directory/postscreen_cache
postscreen_cache_retention_time = 7d
postscreen_client_connection_count_limit = $smtpd_client_connection_count_limit
postscreen_command_count_limit = 20
postscreen_command_filter =
postscreen_command_time_limit = ${stress?10}${stress:300}s
postscreen_disable_vrfy_command = $disable_vrfy_command
postscreen_discard_ehlo_keyword_address_maps = 
$smtpd_discard_ehlo_keyword_address_maps
postscreen_discard_ehlo_keywords = $smtpd_discard_ehlo_keywords
postscreen_dnsbl_action = enforce
postscreen_dnsbl_reply_map = texthash:/usr/local/etc/postfix/dnsbl_reply
postscreen_dnsbl_sites = zen.spamhaus.org*3, bl.mailspike.net*2, 
b.barracudacentral.org*2, bl.spameatingmonkey.net, bl.spamcop.net, 
dnsbl.sorbs.net, psbl.surriel.com, swl.spamhaus.org*-4, 
list.dnswl.org=127.[0..255].[0..255].0*-2, 
list.dnswl.org=127.[0..255].[0..255].1*-3, 
list.dnswl.org=127.[0..255].[0..255].[2..255]*-4, 
wl.mailspike.net=127.0.0.[17;18]*-1, wl.mailspike.net=127.0.0.[19;20]*-2, 
ix.dnsbl.manitu.net, bl.blocklist.de, list.dnswl.org=127.0.[0..255].0*-1, 
list.dnswl.org=127.0.[0..255].1*-2, list.dnswl.org=127.0.[0..255].[2..3]*-3, 
iadb.isipp.com=127.0.[0..255].[0..255]*-2, 
iadb.isipp.com=127.3.100.[6..200]*-2, wl.mailspike.net=127.0.0.[17;18]*-1, 
wl.mailspike.net=127.0.0.[19;20]*-2
postscreen_dnsbl_threshold = 3
postscreen_dnsbl_ttl = 1h
postscreen_dnsbl_whitelist_threshold = -4
postscreen_enforce_tls = $smtpd_enforce_tls
postscreen_expansion_filter = $smtpd_expansion_filter
postscreen_forbidden_commands = $smtpd_forbidden_commands
postscreen_greet_action = enforce
postscreen_greet_banner = Bienvenue et merci d'attendre qu'on vous assigne une 
place
postscreen_greet_ttl = 1d
postscreen_greet_wait = ${stress?2}${stress:6}s
postscreen_helo_required = $smtpd_helo_required
postscreen_non_smtp_command_action = drop
postscreen_non_smtp_command_enable = yes
postscreen_non_smtp_command_ttl = 30d
postscreen_pipelining_action = enforce
postscreen_pipelining_enable = yes
postscreen_pipelining_ttl = 30d
postscreen_post_queue_limit = $default_process_limit
postscreen_pre_queue_limit = $default_process_limit
postscreen_reject_footer = $smtpd_reject_footer
postscreen_tls_security_level = $smtpd_tls_security_level
postscreen_use_tls = $smtpd_use_tls
postscreen_watchdog_timeout = 10s




> On 8 Mar 2016, at 16:37, @lbutlr  wrote:
> 
> On Mar 8, 2016, at 9:15 AM, Robert Chalmers  wrote:
>> I can put them in a postfix blacklist. And possible write a script to update 
>> the list on a daily basis as more are added.
> 
> Are you using postscreen? If not, you should. You’ll see dogs like:
> 
> Mar  8 09:35:20 mail postfix/postscreen[78466]: CONNECT from 
> [196.207.111.150]:55638 to [65.121.55.42]:25
> Mar  8 09:35:21 mail postfix/postscreen[78466]: PREGREET 22 after 0.87 from 
> [196.207.111.150]:55638: HELO 196.207.111.150\r\n
> Mar  8 09:35:21 mail postfix/postscreen[78466]: DNSBL rank 9 for 
> [196.207.111.150]:55638
> Mar  8 09:35:22 mail postfix/postscreen[78466]: NOQUEUE: reject: RCPT from 
> [196.207.111.150]:55638: 450 4.7.1 Service unavailable; client 
> [196.207.111.150] blocked using zen.spamhaus.org; from=<>, to=<*munged*>, 
> proto=SMTP, helo=<196.207.111.150>
> Mar  8 09:35:23 mail postfix/postscreen[78466]: HANGUP after 1.7 from 
> [196.207.111.150]:55638 in tests after SMTP handshake
> 
> If you want to blacklist them, you should look at something like sshguard.
> 
> -- 
> Behind every great man there's a woman with a vibrator -- Hawkeye Pierce
> 

Robert Chalmers
rob...@chalmers.com .au  Quantum Radio: 
http://tinyurl.com/lwwddov
Mac mini 6.2 - 2012, Intel Core i7,2.3 GHz, Memory:16 GB. El-Capitan 10.11.  
XCode 7.2.1
2TB: Drive 0:HGST HTS721010A9E630. Upper bay. Drive 1:ST1000LM024 HN-M101MBB. 
Lower Bay

Re: postfix/smtpd connections from unknown users. Dealing with same?

[@lbutlr]

On Mar 8, 2016, at 9:15 AM, Robert Chalmers  wrote:
> I can put them in a postfix blacklist. And possible write a script to update 
> the list on a daily basis as more are added.

Are you using postscreen? If not, you should. You’ll see dogs like:

Mar  8 09:35:20 mail postfix/postscreen[78466]: CONNECT from 
[196.207.111.150]:55638 to [65.121.55.42]:25
Mar  8 09:35:21 mail postfix/postscreen[78466]: PREGREET 22 after 0.87 from 
[196.207.111.150]:55638: HELO 196.207.111.150\r\n
Mar  8 09:35:21 mail postfix/postscreen[78466]: DNSBL rank 9 for 
[196.207.111.150]:55638
Mar  8 09:35:22 mail postfix/postscreen[78466]: NOQUEUE: reject: RCPT from 
[196.207.111.150]:55638: 450 4.7.1 Service unavailable; client 
[196.207.111.150] blocked using zen.spamhaus.org; from=<>, to=<*munged*>, 
proto=SMTP, helo=<196.207.111.150>
Mar  8 09:35:23 mail postfix/postscreen[78466]: HANGUP after 1.7 from 
[196.207.111.150]:55638 in tests after SMTP handshake

If you want to blacklist them, you should look at something like sshguard.

-- 
Behind every great man there's a woman with a vibrator -- Hawkeye Pierce

Re: postfix/smtpd connections from unknown users. Dealing with same?

[Wietse Venema]

Robert Chalmers:
> This afternoon, over the course of about 4 hours, I?ve logged 741
> connections like this.
> 
> Mar  8 15:05:46 zeus postfix/smtpd[92324]: connect from unknown[185.130.5.90]
> Mar  8 15:07:30 zeus postfix/smtpd[92616]: connect from 
> unknown[131.161.138.190]
> Mar  8 15:07:39 zeus postfix/smtpd[92324]: connect from 
> unknown[113.160.205.81]
> Mar  8 15:07:45 zeus postfix/smtpd[92616]: connect from 
> unknown[181.142.12.223]
> Mar  8 15:08:00 zeus postfix/smtpd[92324]: connect from unknown[181.168.4.42]
> Mar  8 15:08:00 zeus postfix/smtpd[93053]: connect from 
> unknown[116.105.182.54]

If the load bothers you, let it be handled by postscreen with a few
good DNSBLs (on my machine, that eliminates 90% of inbound SMTP
connections; only 10% end up talking to an smtpd process).

> So, is the best way of dealing with this list of numbers, and I
> can extract - and have extracted - just the ip numbers.

Don't waste your time. The odds that the same client keeps coming
back are small.

Wietse

postfix/smtpd connections from unknown users. Dealing with same?

[Robert Chalmers]

This afternoon, over the course of about 4 hours, I’ve logged 741 connections 
like this.

Mar  8 15:05:46 zeus postfix/smtpd[92324]: connect from unknown[185.130.5.90]
Mar  8 15:07:30 zeus postfix/smtpd[92616]: connect from unknown[131.161.138.190]
Mar  8 15:07:39 zeus postfix/smtpd[92324]: connect from unknown[113.160.205.81]
Mar  8 15:07:45 zeus postfix/smtpd[92616]: connect from unknown[181.142.12.223]
Mar  8 15:08:00 zeus postfix/smtpd[92324]: connect from unknown[181.168.4.42]
Mar  8 15:08:00 zeus postfix/smtpd[93053]: connect from unknown[116.105.182.54]

of course they have all been refused.
On checking with awk/grep etc, it comes down to 78 unique IP addresses. I don’t 
have IPv6 here, so that makes it easier.

The mail.log file is continuously scrolling so it is putting some load on the 
system and the connection.

So, is the best way of dealing with this list of numbers, and I can extract - 
and have extracted - just the ip numbers.

I can put them in a postfix blacklist. And possible write a script to update 
the list on a daily basis as more are added.
If they are in such a list, they still “get to the system” though yes?

I can put them the system (firewall) blacklist (pf.conf), And possible write a 
script to update the list on a daily basis as more are added.
If they are in that list, they are blocked at the gate as it were.

Is it even worth worrying about them - the numbers so far aren’t huge… and each 
connection is dropped after a few processes.

Robert

Re: Unknown users not rejected on Alias Domains (Virtual Domains)

[Alex JOST]

Am 03.06.2014 22:50, schrieb Peter Bittner:

Hi,

I'm trying to find out which is the correct way to configure alias
domains on postfix.

For example, I have 3 different domains (example.com, example.info,
example.net), and when I send an e-mail to a user on any of the three
domains it's always sent to u...@example.com.
In other words, I never need to configure mailboxes or users on any of
the other two domains (alias domains, as I call them). It's
sufficient to have the user configured on the main domain.


AFAIK, Postfix Admin can do what you are asking for.
http://sourceforge.net/projects/postfixadmin/

--
Alex JOST

Unknown users not rejected on Alias Domains (Virtual Domains)

[Peter Bittner]

Hi,

I'm trying to find out which is the correct way to configure alias
domains on postfix.

For example, I have 3 different domains (example.com, example.info,
example.net), and when I send an e-mail to a user on any of the three
domains it's always sent to u...@example.com.
In other words, I never need to configure mailboxes or users on any of
the other two domains (alias domains, as I call them). It's
sufficient to have the user configured on the main domain.

I've seen the following resources on that topic:
- https://workaround.org/ispmail/wheezy/virtual-domains
- http://www.postfix.org/VIRTUAL_README.html#forwarding

Unfortunately, those resources only describe the following types of forwarding:
- j...@example.info -- jane@somewhere-else
- @example.info -- jim@somewhere-else (catch-all feature)

What I would need is a correctly working solution of:
- @example.info -- @somewhere-else, or
- any@example.info -- any@somewhere-else

Doing some tests with some test configuration
sending/forwarding/retrieving seems to work (e-mails sent to one of
the alias domains arrive at the main domain), but if there is a
non-existing mailbox on the main domain and the e-mail is sent to the
corresponding user at one of the alias domains no e-mail bounces back
from the main domain saying that the mail could not be delivered.

How can I make postfix bounce e-mails back when there is no user for
it on the main domain? Is there a specific, standard way of doing
alias domains on postfix? (It should be some kind of standard
use-case after all, shouldn't it? Google Mail let you define alias
domains on Google Apps, and that simply works.)

Thanks in advance for any hints,
Peter

Re: Unknown users not rejected on Alias Domains (Virtual Domains)

[Noel Jones]

On 6/3/2014 3:50 PM, Peter Bittner wrote:
 Hi,
 
 I'm trying to find out which is the correct way to configure alias
 domains on postfix.
 
 For example, I have 3 different domains (example.com, example.info,
 example.net), and when I send an e-mail to a user on any of the three
 domains it's always sent to u...@example.com.
 In other words, I never need to configure mailboxes or users on any of
 the other two domains (alias domains, as I call them). It's
 sufficient to have the user configured on the main domain.
 
 I've seen the following resources on that topic:
 - https://workaround.org/ispmail/wheezy/virtual-domains
 - http://www.postfix.org/VIRTUAL_README.html#forwarding
 
 Unfortunately, those resources only describe the following types of 
 forwarding:
 - j...@example.info -- jane@somewhere-else
 - @example.info -- jim@somewhere-else (catch-all feature)
 
 What I would need is a correctly working solution of:
 - @example.info -- @somewhere-else, or
 - any@example.info -- any@somewhere-else
 
 Doing some tests with some test configuration
 sending/forwarding/retrieving seems to work (e-mails sent to one of
 the alias domains arrive at the main domain), but if there is a
 non-existing mailbox on the main domain and the e-mail is sent to the
 corresponding user at one of the alias domains no e-mail bounces back
 from the main domain saying that the mail could not be delivered.
 
 How can I make postfix bounce e-mails back when there is no user for
 it on the main domain? Is there a specific, standard way of doing
 alias domains on postfix? (It should be some kind of standard
 use-case after all, shouldn't it? Google Mail let you define alias
 domains on Google Apps, and that simply works.)
 
 Thanks in advance for any hints,
 Peter
 


If your mail is delivered locally to standard system users, you can
just add all the domains to mydestination and it just works; no
alias mapping needed, all users appear in all domains.

If the domains are virtual, you need to use 1-1 address mapping. Do
not use wildcard domain mapping, as wildcards defeat the automatic
recipient validation of postfix.


  -- Noel  Jones

Re: avoid outgoing mail sent to unknown users

[Alexandre Ellert]

 but that *does not* help in case of the OP
 read the thread start
 
 it is simply impossible doing on one hand RCPT-verification because
 no verification on the root-cause (webserver) but at the same time
 not reject messages from the webserver in case verification on the
 final destination is not possible due greylisting or other temp errors
 
 there is no workaround at all, fix the web-application or live
 with the bad impact of not doing so

As I said, there's no way to fix some web-application.

After few day with reject_unverified_recipient enabled for some mail account, I 
come into trouble.
One mail provider deferred my mail because I do email verification (he tracks 
transaction aborted after RCP-TO).

So, I roll back my Postfix configuration and now I'm looking for another 
solution.

Is there anyway to populate a cache (file, SQL, …) with real hard bounces from 
remote SMTP and tell postfix to stop send mail to these addresses next time ?

Re: avoid outgoing mail sent to unknown users

[Wietse Venema]

Alexandre Ellert:
 Is there anyway to populate a cache (file, SQL, ?) with real hard
 bounces from remote SMTP and tell postfix to stop send mail to
 these addresses next time ?

Postfix logs remote SMTP server responses. You provide a tool
that populates a table with bad addresses, and you configure
Postfix to query that table.

Wietse

Re: avoid outgoing mail sent to unknown users

[Benny Pedersen]

Alexandre Ellert skrev den 2014-01-10 22:12:

How can I tell Postfix to queue the mail in case of remote reply 4xx ?


4xx is softfails, so you already do

Re: avoid outgoing mail sent to unknown users

[li...@rhsoft.net]

Am 11.01.2014 18:57, schrieb Benny Pedersen:
 Alexandre Ellert skrev den 2014-01-10 22:12:
 How can I tell Postfix to queue the mail in case of remote reply 4xx ?
 
 4xx is softfails, so you already do

but that *does not* help in case of the OP
read the thread start

it is simply impossible doing on one hand RCPT-verification because
no verification on the root-cause (webserver) but at the same time
not reject messages from the webserver in case verification on the
final destination is not possible due greylisting or other temp errors

there is no workaround at all, fix the web-application or live
with the bad impact of not doing so

Re: avoid outgoing mail sent to unknown users

[Alexandre Ellert]

 Wietse :
 You can push the problem back to the webservers, by using the the
 Postfix SMTP server's reject_unverified_recipient feature.
 
 With this, Postfix will make one connection for the recipient
 address, and then the Postfix SMTP server answers with 5XX to the
 web application when that recipient does not exist.
 
 There are no repeated connections, because Postfix stores the results
 in a cache (both positive and negative).

Very nice, that way the customer website would get a bounce the second time it 
sends to an invalid address.

 Noel :
 Consider how the website might react when mail is rejected. I don't
 suppose they'll all show the end user a helpful message about a bad
 address.  Probably need to work with your customers on this so there
 are no surprises.

That's would not be my problem anymore :) Customer should then put some code to 
handle bounce or better to verify email at subscription time.

 Wietse :
 For details: http://www.postfix.org/ADDRESS_VERIFICATION_README.html
 
 You'll have to adjust some settings so that Postfix replies with
 5xx (by default it replies with 4xx to be on the safe side).

I read carefully Limitations of address verification and I would limit scope 
to those particular accounts which doesn't care about email verification.

I already isolated them in a transport map to use a dedicated IP :
# main.cf
sender_dependent_default_transport_maps = hash:/etc/postfix/sender_transport
$ cat /etc/postfix/sender_transport
website_sen...@domain1.com  out_transactionnal:
website_sen...@domain2.com  out_transactionnal:
# master.cf
out_transactionnal unix -   -   n   -   -   smtp
   -o smtp_bind_address=188.165.xx.xx
   -o syslog_name=postfix-transactionnal

Should I apply address verification this way :
# master.cf
out_transactionnal unix -   -   n   -   -   smtp
   -o smtp_bind_address=188.165.xx.xx
   -o syslog_name=postfix-transactionnal
   -o smtpd_recipient_restrictions=reject_unverified_recipient

Would it break something to override this way ?
(Would it break my submission override -o 
smtpd_recipient_restrictions=permit_sasl_authenticated,permit_mynetworks,reject
 ?)

Thanks.

Re: avoid outgoing mail sent to unknown users

[Wietse Venema]

Alexandre Ellert:
  Wietse :
  You can push the problem back to the webservers, by using the the
  Postfix SMTP server's reject_unverified_recipient feature.
  
  With this, Postfix will make one connection for the recipient
  address, and then the Postfix SMTP server answers with 5XX to the
  web application when that recipient does not exist.
  
  There are no repeated connections, because Postfix stores the results
  in a cache (both positive and negative).
 
 Very nice, that way the customer website would get a bounce the
 second time it sends to an invalid address.

No, it gets a bounce the first time.

  Wietse :
  For details: http://www.postfix.org/ADDRESS_VERIFICATION_README.html
  
  You'll have to adjust some settings so that Postfix replies with
  5xx (by default it replies with 4xx to be on the safe side).
 
 I read carefully Limitations of address verification and I would
 limit scope to those particular accounts which doesn't care about
 email verification.

In that case use:

/etc/postfix/main.cf:
smtpd_recipient_restrictions =
...
check_sender_access hash:/etc/postfix/sender_access
...

/etc/postfix/sender_access:
x...@example.com reject_unverified_recipient
example.net reject_unverified_recipient
example.org reject_unverified_recipient

Note that address verification requires that this Postfix MTA
can talk directly to the remote MX host.

Wietse

Re: avoid outgoing mail sent to unknown users

[Alexandre Ellert]

 Wietse :
 In that case use:
 
 /etc/postfix/main.cf:
smtpd_recipient_restrictions =
...
check_sender_access hash:/etc/postfix/sender_access
...
 
 /etc/postfix/sender_access:
x...@example.com reject_unverified_recipient
example.net reject_unverified_recipient
example.org reject_unverified_recipient
 
 Note that address verification requires that this Postfix MTA
 can talk directly to the remote MX host.

This works like a charm.

One last thing, concerning order of smtpd_recipient_restrictions, I currently 
have this in master.cf :

submission inet n   -   -   -   -   smtpd
  ...
 -o 
smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unknown_recipient_domain,check_sender_access,hash:/etc/postfix/verify_recipient,reject

Can you confirm that in case of greylisting at the destination SMTP, it will 
work fine ?

Re: avoid outgoing mail sent to unknown users

[Alexandre Ellert]

 This works like a charm.
 
 One last thing, concerning order of smtpd_recipient_restrictions, I currently 
 have this in master.cf :
 
 submission inet n   -   -   -   -   smtpd
  ...
 -o 
 smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unknown_recipient_domain,check_sender_access,hash:/etc/postfix/verify_recipient,reject
 
 Can you confirm that in case of greylisting at the destination SMTP, it will 
 work fine ?


Address verification doesn't work :
-o 
smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unknown_recipient_domain,check_sender_access,hash:/etc/postfix/verify_recipient,reject

Address verification works :
-o 
smtpd_recipient_restrictions=reject_unknown_recipient_domain,check_sender_access,hash:/etc/postfix/verify_recipient,permit_mynetworks,permit_sasl_authenticated,reject

I wonder if greylisting would cause problem with address verification enabled..

Re: avoid outgoing mail sent to unknown users

[Wietse Venema]

Alexandre Ellert:
[reject_unverified_recipient]
 Can you confirm that in case of greylisting at the destination
 SMTP, it will work fine ?

If the remote SMTP server uses greylisting, then the address
verification result will be don't know (*) and the Postfix SMTP server
will reply with 4xx (unless you configure Postfix otherwise).

Wietse
(*) The Postfix SMTP client does not distiunguish between different
kinds of temporary error responses.

Re: avoid outgoing mail sent to unknown users

[Alexandre Ellert]

 Wietse :
 If the remote SMTP server uses greylisting, then the address
 verification result will be don't know (*) and the Postfix SMTP server
 will reply with 4xx (unless you configure Postfix otherwise).
 
   Wietse
 (*) The Postfix SMTP client does not distiunguish between different
 kinds of temporary error responses.

Ok, big thanks for all explanations

Re: avoid outgoing mail sent to unknown users

[Alexandre Ellert]

 Wietse :
 If the remote SMTP server uses greylisting, then the address
 verification result will be don't know (*) and the Postfix SMTP server
 will reply with 4xx (unless you configure Postfix otherwise).
 
   Wietse
 (*) The Postfix SMTP client does not distiunguish between different
 kinds of temporary error responses.

I made more tests and greylisting is still a problem.

I've tried with :
unverified_recipient_tempfail_action = permit
in main.cf

But I got :
fatal: bad configuration
in mail.log

How can I tell Postfix to queue the mail in case of remote reply 4xx ?

Re: avoid outgoing mail sent to unknown users

[Alexandre Ellert]

 I made more tests and greylisting is still a problem.
 
 I've tried with :
 unverified_recipient_tempfail_action = permit
 in main.cf
 
 But I got :
 fatal: bad configuration
 in mail.log
 
 How can I tell Postfix to queue the mail in case of remote reply 4xx ?
 

I answer to myself, it seems that :
unverified_recipient_defer_code = 250
Did the trick :)

Re: avoid outgoing mail sent to unknown users

[Wietse Venema]

Alexandre Ellert:
 But I got :
 fatal: bad configuration
 in mail.log

Show the complete logfile record!

Wietse

avoid outgoing mail sent to unknown users

[Alexandre Ellert]

Hi,

I relay transactional mail for my customer's web sites.
Each website has it's own SASL authenticated account and mail are sent via 
submission or smtps.

But, some website doesn't verify email existence when a user submit a web form  
or 'create an account'.
That's why I often see my postfix relay trying to send to non-existing email.
Sending again and again to non-existing mail can lowering my IP reputation and 
waste ressources that's why I need a solution.

I can't force my customer to use some kind of email verification but I strongly 
encouraged them to do it. Most of them don't care or have no 
time/money/knowlegde to do it.

Fisrt, I need to have some stats about outgoing mail.
- What percentage of error 'User unknown' per account ? (Can you confirm that 
every SMTP software bounce with error '550 5.1.1'  ?)
If someone can advice any script, I will be very grateful. Otherwise, i will 
write it myself.
With these stats, I can then take necessary actions (lock account, …)

Second, maybe additional, I think about maintain a list of 'User unknown' 
address.
Maybe, I could implement this (example with plain text file but it could be 
SQL):

# master.cf
submission inet n   -   -   -   -   smtpd
  -o 
smtpd_recipient_restrictions=check_recipient_access,hash:/etc/postfix/unknonwn_recipients,permit_sasl_authenticated,permit_mynetworks,reject
smtps inet n   -   -   -   -   smtpd
  -o smtpd_tls_wrappermode=yes
  -o 
smtpd_recipient_restrictions=check_recipient_access,hash:/etc/postfix/unknonwn_recipients,permit_sasl_authenticated,permit_mynetworks,reject

$ cat /etc/postfix/unknonwn_recipients
bad_us...@example.com REJECT Unknown user
bad_us...@example.com REJECT Unknown user

And write a cron job to parse postfix logs and add 'Unknown user' email to  
/etc/postfix/unknonwn_recipients.

Thank you for your feedback.

Alexandre

Re: avoid outgoing mail sent to unknown users

[Wietse Venema]

Alexandre Ellert:
 Hi,
 
 I relay transactional mail for my customer's web sites.
 Each website has it's own SASL authenticated account and mail are
 sent via submission or smtps.
 
 But, some website doesn't verify email existence when a user submit
 a web form  or 'create an account'.
 That's why I often see my postfix relay trying to send to non-existing
 email.
 Sending again and again to non-existing mail can lowering my IP
 reputation and waste ressources that's why I need a solution.

You can push the problem back to the webservers, by using the the
Postfix SMTP server's reject_unverified_recipient feature.

With this, Postfix will make one connection for the recipient
address, and then the Postfix SMTP server answers with 5XX to the
web application when that recipient does not exist.

There are no repeated connections, because Postfix stores the results
in a cache (both positive and negative).

For details: http://www.postfix.org/ADDRESS_VERIFICATION_README.html

You'll have to adjust some settings so that Postfix replies with
5xx (by default it replies with 4xx to be on the safe side).

Wietse

Re: avoid outgoing mail sent to unknown users

[Noel Jones]

On 1/9/2014 4:41 PM, Alexandre Ellert wrote:
 Hi,
 
 I relay transactional mail for my customer's web sites.
 Each website has it's own SASL authenticated account and mail are
 sent via submission or smtps.
 
 But, some website doesn't verify email existence when a user submit
 a web form  or 'create an account'.
 That's why I often see my postfix relay trying to send to
 non-existing email.
 Sending again and again to non-existing mail can lowering my IP
 reputation and waste ressources that's why I need a solution.
 
 I can't force my customer to use some kind of email verification but
 I strongly encouraged them to do it. Most of them don't care or have
 no time/money/knowlegde to do it.
 
 Fisrt, I need to have some stats about outgoing mail.
 - What percentage of error 'User unknown' per account ? (Can you
 confirm that every SMTP software bounce with error '550 5.1.1'  ?)
 If someone can advice any script, I will be very grateful.
 Otherwise, i will write it myself.
 With these stats, I can then take necessary actions (lock account, …)

There are several log analysis tools listed here:
http://www.postfix.org/addon.html#logfile

And also the excellent postfix-logwatch module, which works fine
without the logwatch framework. I don't know why this isn't listed
on the postfix site; probably because the author never requested it.
http://www.postfix.org/addon.html#logfile

 
 Second, maybe additional, I think about maintain a list of 'User
 unknown' address.
 Maybe, I could implement this (example with plain text file but it
 could be SQL):
 
 # master.cf
 submission inet n   -   -   -   -   smtpd
   -o
 smtpd_recipient_restrictions=check_recipient_access,hash:/etc/postfix/unknonwn_recipients,permit_sasl_authenticated,permit_mynetworks,reject
 smtps inet n   -   -   -   -   smtpd
   -o smtpd_tls_wrappermode=yes
   -o
 smtpd_recipient_restrictions=check_recipient_access,hash:/etc/postfix/unknonwn_recipients,permit_sasl_authenticated,permit_mynetworks,reject
 
 $ cat /etc/postfix/unknonwn_recipients
 bad_us...@example.com mailto:bad_us...@example.com REJECT Unknown user
 bad_us...@example.com mailto:bad_us...@example.com REJECT Unknown user

Consider how the website might react when mail is rejected. I don't
suppose they'll all show the end user a helpful message about a bad
address.  Probably need to work with your customers on this so there
are no surprises.

 
 And write a cron job to parse postfix logs and add 'Unknown user'
 email to  /etc/postfix/unknonwn_recipients.

You'll also need to have some method to expire addresses
periodically that become good at a later date, and limits to how
often an address is probed.

Or use the built-in postfix reject_unverified_recipient function,
where those particular problems are already solved.
http://www.postfix.org/ADDRESS_VERIFICATION_README.html


  -- Noel Jones

Re: avoid outgoing mail sent to unknown users

[Noel Jones]

On 1/9/2014 5:01 PM, Noel Jones wrote:
 On 1/9/2014 4:41 PM, Alexandre Ellert wrote:
 Hi,

 I relay transactional mail for my customer's web sites.
 Each website has it's own SASL authenticated account and mail are
 sent via submission or smtps.

 But, some website doesn't verify email existence when a user submit
 a web form  or 'create an account'.
 That's why I often see my postfix relay trying to send to
 non-existing email.
 Sending again and again to non-existing mail can lowering my IP
 reputation and waste ressources that's why I need a solution.

 I can't force my customer to use some kind of email verification but
 I strongly encouraged them to do it. Most of them don't care or have
 no time/money/knowlegde to do it.

 Fisrt, I need to have some stats about outgoing mail.
 - What percentage of error 'User unknown' per account ? (Can you
 confirm that every SMTP software bounce with error '550 5.1.1'  ?)
 If someone can advice any script, I will be very grateful.
 Otherwise, i will write it myself.
 With these stats, I can then take necessary actions (lock account, …)
 
 There are several log analysis tools listed here:
 http://www.postfix.org/addon.html#logfile
 
 And also the excellent postfix-logwatch module, which works fine
 without the logwatch framework. I don't know why this isn't listed
 on the postfix site; probably because the author never requested it.
 http://www.postfix.org/addon.html#logfile

Wrong link. Copy/Paste failure.
http://logreporters.sourceforge.net/


  -- Noel Jones

 

 Second, maybe additional, I think about maintain a list of 'User
 unknown' address.
 Maybe, I could implement this (example with plain text file but it
 could be SQL):

 # master.cf
 submission inet n   -   -   -   -   smtpd
   -o
 smtpd_recipient_restrictions=check_recipient_access,hash:/etc/postfix/unknonwn_recipients,permit_sasl_authenticated,permit_mynetworks,reject
 smtps inet n   -   -   -   -   smtpd
   -o smtpd_tls_wrappermode=yes
   -o
 smtpd_recipient_restrictions=check_recipient_access,hash:/etc/postfix/unknonwn_recipients,permit_sasl_authenticated,permit_mynetworks,reject

 $ cat /etc/postfix/unknonwn_recipients
 bad_us...@example.com mailto:bad_us...@example.com REJECT Unknown user
 bad_us...@example.com mailto:bad_us...@example.com REJECT Unknown user
 
 Consider how the website might react when mail is rejected. I don't
 suppose they'll all show the end user a helpful message about a bad
 address.  Probably need to work with your customers on this so there
 are no surprises.
 

 And write a cron job to parse postfix logs and add 'Unknown user'
 email to  /etc/postfix/unknonwn_recipients.
 
 You'll also need to have some method to expire addresses
 periodically that become good at a later date, and limits to how
 often an address is probed.
 
 Or use the built-in postfix reject_unverified_recipient function,
 where those particular problems are already solved.
 http://www.postfix.org/ADDRESS_VERIFICATION_README.html
 
 
   -- Noel Jones
 

Re: Rejecting mail to unknown users

[Zel Uneec]

On 11.09.2013 16:52, Kris Deugau wrote:

Mark Goodge wrote:

It might help if you explained why you want to do this. What particular
problem is being caused by your internal users getting an error message
instead of a bounce?


Some idiot mail clients (*cough*ManyversionsofOutlook*cough*) don't
actually display the SMTP error response to the user, they just pop up a
generic Wahh!  Can't do that! error message.

Some users are also quite resistant to actually *reading* the text of
the error (although these users will also have trouble with reading the
bounce message).



Exactly!


On 11.09.2013 15:27, Wietse Venema wrote:
 Thank you Wietse, that is what I was looking for! So, for now, my
 problem is solved.

 Just one more thing: Will this setting have some kind of (big) negative
 impact? I guess not, but just to be sure...

 Yes. When a client becomes malware infected, it will send spam with
 a false sender address, and Postfix will return some of that spam
 to innocent people.

Can you please explain how is this connected? If client is infected, it 
can send spam with false sender address no matter if sending to uknown 
recipients is enabled or disabled, if it has access to smtp 
(sasl_authenticated, etc.)?

Re: Rejecting mail to unknown users

[Wietse Venema]

Zel Uneec:
[ Charset ISO-8859-2 unsupported, converting... ]
 On 11.09.2013 16:52, Kris Deugau wrote:
  Mark Goodge wrote:
  It might help if you explained why you want to do this. What particular
  problem is being caused by your internal users getting an error message
  instead of a bounce?
 
  Some idiot mail clients (*cough*ManyversionsofOutlook*cough*) don't
  actually display the SMTP error response to the user, they just pop up a
  generic Wahh!  Can't do that! error message.
 
  Some users are also quite resistant to actually *reading* the text of
  the error (although these users will also have trouble with reading the
  bounce message).
 
 
 Exactly!
 
 
 On 11.09.2013 15:27, Wietse Venema wrote:
   Thank you Wietse, that is what I was looking for! So, for now, my
   problem is solved.
  
   Just one more thing: Will this setting have some kind of (big) negative
   impact? I guess not, but just to be sure...
  
   Yes. When a client becomes malware infected, it will send spam with
   a false sender address, and Postfix will return some of that spam
   to innocent people.
 
 Can you please explain how is this connected? If client is infected, it 
 can send spam with false sender address no matter if sending to uknown 
 recipients is enabled or disabled, if it has access to smtp 
 (sasl_authenticated, etc.)?

With the proposed modification, Postfix will not reject spam for
an unknown recipient from a local or authenticated client, and will
instead send a bounce message to the forged sender address.

Wietse

Rejecting mail to unknown users

[Zel Uneec]

Hello everyone!

I need your help setting up postfix.

This is my problem/question: I have multiple domains on my mail server 
running postfix (adn dovecot), with LDAP based user accounts. When 
someone from outside (that is: not from my domains) sends mail to a 
user that does not exist, he gets a bounce message that the given mail 
account/user does not exist on server. But, when someone from inside 
(from one of my domains) tries to send mail to non existing user, he is 
not able to send e-mail, and mail clients give him reject code (some 
with explanation that account/user does not exist, some with no 
explanation).


What I want to do is to set postfix to let those inside mails pass 
too, and then recive bounce mail with note that user does not exist 
(that is, the same behavior as when someone from outside sends mail to 
non existing user).


I've tried numerous changes in main.cf, but could not achieve this 
behaviour. Is it even possible?


Thanks,

Zel

Re: Rejecting mail to unknown users

[Mark Goodge]

On 11/09/2013 12:23, Zel Uneec wrote:

Hello everyone!

I need your help setting up postfix.

This is my problem/question: I have multiple domains on my mail server
running postfix (adn dovecot), with LDAP based user accounts. When
someone from outside (that is: not from my domains) sends mail to a
user that does not exist, he gets a bounce message that the given mail
account/user does not exist on server. But, when someone from inside
(from one of my domains) tries to send mail to non existing user, he is
not able to send e-mail, and mail clients give him reject code (some
with explanation that account/user does not exist, some with no
explanation).

What I want to do is to set postfix to let those inside mails pass
too, and then recive bounce mail with note that user does not exist
(that is, the same behavior as when someone from outside sends mail to
non existing user).


It might help if you explained why you want to do this. What particular 
problem is being caused by your internal users getting an error message 
instead of a bounce?


As a general rule, sending a bounce is a last resort, something that you 
do when you can't reject a message. That's how the system is designed to 
work, and sending a bounce when you don't need to is generally 
considered bad practice.


Mark
--
My blog: http://mark.goodge.co.uk

Re: Rejecting mail to unknown users

[Zel Uneec]

On 11.09.2013 13:31, Mark Goodge wrote:

It might help if you explained why you want to do this. What particular
problem is being caused by your internal users getting an error message
instead of a bounce?

As a general rule, sending a bounce is a last resort, something that you
do when you can't reject a message. That's how the system is designed to
work, and sending a bounce when you don't need to is generally
considered bad practice.

Mark


This is why: previously we used qmail, but I decided to migrate to 
postfix+dovecot. On previous mail server installation (qmail) we had the 
behaviour I now want to achieve - bounce mails for everyone, not only 
outsiders, and thus no error message while trying to send to unknown user.


Particular problem: my boss (and his Mac Mail). :)

My boss wants this functionality. With old mail server, he could send 
mail to numerous addresses, and if one of them does not exist, he would 
recieve a bounce mail note for non existing user, but mails to valid 
users will be sent. Now, if he misspells only one address, the mail is 
not sent at all, nor even to valid addresses. That's how he sees it. No 
matter what I say and try to explain which is better and why. He wants 
the old functionality, as it is better for him.


So, here's one more additional question from me: why is it so 
problematic if inside (my domains) users send mails to non existing mail 
addresses? I assume this would not happen so often to have some impact 
on server. Much much more impact have outsider mails to non existing 
addresses.

Re: Rejecting mail to unknown users

[/dev/rob0]

On Wed, Sep 11, 2013 at 01:23:01PM +0200, Zel Uneec wrote:
 This is my problem/question: I have multiple domains on my mail 
 server running postfix (adn dovecot), with LDAP based user 
 accounts. When someone from outside (that is: not from my 
 domains) sends mail to a user that does not exist, he gets a bounce 
 message that the given mail account/user does not exist on server.

No, not from your server, anyway. Your server rejects the mail from 
the remote client, and that MTA generates the bounce for their own 
user.

 But, when someone from inside (from one of my domains) tries to 

From one of my domains? Do you mean from your networks?

 send mail to non existing user, he is not able to send e-mail, and 
 mail clients give him reject code (some with explanation that 
 account/user does not exist, some with no explanation).
 
 What I want to do is to set postfix to let those inside mails 
 pass too, and then recive bounce mail with note that user does
 not exist

This is what happens if permit_mynetworks precedes any other 
reatrictions you may have set.

 (that is, the same behavior as when someone from outside sends
 mail to non existing user).

No, it is not. But in effect it is similar, if their MTA sent a 
bounce. I guess that's what you mean?

 I've tried numerous changes in main.cf, but could not achieve
 this behaviour. Is it even possible?

Of course it is. But it is not possible to guess what you did.

http://www.postfix.org/DEBUG_README.html#mail
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if /dev/rob0 is in the Subject:

Re: Rejecting mail to unknown users

[Wietse Venema]

/dev/rob0:
 On Wed, Sep 11, 2013 at 01:23:01PM +0200, Zel Uneec wrote:
  This is my problem/question: I have multiple domains on my mail 
  server running postfix (adn dovecot), with LDAP based user 
  accounts. When someone from outside (that is: not from my 
  domains) sends mail to a user that does not exist, he gets a bounce 
  message that the given mail account/user does not exist on server.
 
 No, not from your server, anyway. Your server rejects the mail from 
 the remote client, and that MTA generates the bounce for their own 
 user.
 
  But, when someone from inside (from one of my domains) tries to 
 
 From one of my domains? Do you mean from your networks?
 
  send mail to non existing user, he is not able to send e-mail, and 
  mail clients give him reject code (some with explanation that 
  account/user does not exist, some with no explanation).
  
  What I want to do is to set postfix to let those inside mails 
  pass too, and then recive bounce mail with note that user does
  not exist
 
 This is what happens if permit_mynetworks precedes any other 
 reatrictions you may have set.

It is slightly different. The user unknown test is enabled by
default:

Built-in default:
smtpd_reject_unlisted_recipient = yes

With this, there is an implicit reject_unlisted_recipient
that is enforcedi for all clients.

To accept mail from local clients to unknown recipients, while
blocking mail from remote clients to unknown recipients, you
have to specify the reject_unlisted_recipient explicitly.

/etc/postfix/main.cf:
smtpd_reject_unlisted_recipient = no
smtpd_recipient_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_unlisted_recipient
...
reject_unauth_destination
...

It's is very easy to screw this up and become a backscatter source.
That is why smtpd_reject_unlisted_recipient = no is not the default
setting.

http://www.postfix.org/postconf.5.html#smtpd_reject_unlisted_recipient
http://www.postfix.org/postconf.5.html#reject_unlisted_recipient

Wietse

Re: Rejecting mail to unknown users

[Zel Uneec]

On 11.09.2013 14:43, Wietse Venema wrote:

/etc/postfix/main.cf:
 smtpd_reject_unlisted_recipient = no
 smtpd_recipient_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_unlisted_recipient
...
reject_unauth_destination
...

It's is very easy to screw this up and become a backscatter source.
That is why smtpd_reject_unlisted_recipient = no is not the default
setting.



Thank you Wietse, that is what I was looking for! So, for now, my 
problem is solved.


Just one more thing: Will this setting have some kind of (big) negative 
impact? I guess not, but just to be sure...


Thank you, once again.

Cheers,

Zel

Re: Rejecting mail to unknown users

[Wietse Venema]

Zel Uneec:
 On 11.09.2013 14:43, Wietse Venema wrote:
  /etc/postfix/main.cf:
   smtpd_reject_unlisted_recipient = no
   smtpd_recipient_restrictions =
   permit_mynetworks
   permit_sasl_authenticated
   reject_unlisted_recipient
   ...
   reject_unauth_destination
   ...
 
  It's is very easy to screw this up and become a backscatter source.
  That is why smtpd_reject_unlisted_recipient = no is not the default
  setting.
 
 
 Thank you Wietse, that is what I was looking for! So, for now, my 
 problem is solved.
 
 Just one more thing: Will this setting have some kind of (big) negative 
 impact? I guess not, but just to be sure...

Yes. When a client becomes malware infected, it will send spam with
a false sender address, and Postfix will return some of that spam
to innocent people.

Wietse

Re: Rejecting mail to unknown users

[Vishal Agarwal]

Is there any way to control the malware infected  computer, not to send
more then counted or limited messages.


On Wed, Sep 11, 2013 at 6:57 PM, Wietse Venema wie...@porcupine.org wrote:

 Zel Uneec:
  On 11.09.2013 14:43, Wietse Venema wrote:
   /etc/postfix/main.cf:
smtpd_reject_unlisted_recipient = no
smtpd_recipient_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_unlisted_recipient
...
reject_unauth_destination
...
  
   It's is very easy to screw this up and become a backscatter source.
   That is why smtpd_reject_unlisted_recipient = no is not the default
   setting.
  
 
  Thank you Wietse, that is what I was looking for! So, for now, my
  problem is solved.
 
  Just one more thing: Will this setting have some kind of (big) negative
  impact? I guess not, but just to be sure...

 Yes. When a client becomes malware infected, it will send spam with
 a false sender address, and Postfix will return some of that spam
 to innocent people.

 Wietse

Re: Rejecting mail to unknown users

[Noel Jones]

On 9/11/2013 9:18 AM, Vishal Agarwal wrote:
 Is there any way to control the malware infected  computer, not to
 send more then counted or limited messages.

There are several policy services that implement rate limits.
postfwd is one that is commonly used.

http://www.postfix.org/SMTPD_POLICY_README.html
http://www.postfix.org/addon.html#policy



  -- Noel Jones

Re: Rejecting mail to unknown users

[li...@rhsoft.net]

Am 11.09.2013 16:52, schrieb Kris Deugau:
 Mark Goodge wrote:
 It might help if you explained why you want to do this. What particular
 problem is being caused by your internal users getting an error message
 instead of a bounce?
 
 Some idiot mail clients (*cough*ManyversionsofOutlook*cough*) don't
 actually display the SMTP error response to the user, they just pop up a
 generic Wahh!  Can't do that! error message

iPhones do not show the errors at all as well as ignoring the 5xx
repsonse a try over months and weeks to send the same message
every 5 minutes by stupidity

but that is no reason to generate bounces

Re: Rejecting mail to unknown users

[Kris Deugau]

Mark Goodge wrote:
 It might help if you explained why you want to do this. What particular
 problem is being caused by your internal users getting an error message
 instead of a bounce?

Some idiot mail clients (*cough*ManyversionsofOutlook*cough*) don't
actually display the SMTP error response to the user, they just pop up a
generic Wahh!  Can't do that! error message.

Some users are also quite resistant to actually *reading* the text of
the error (although these users will also have trouble with reading the
bounce message).

-kgd

Problem with rejecting mail to unknown users

[Martin Kruse Jensen]

Hi.

I'e got a problem I've been trying to solve for some time now, but I 
can't seem to get it to work. I'm running Postfix on FreeBSD with 
Maildrop delivery, SASL authentification and PostGreSQL backend. However 
I'm sending tons of backscatter because Postfix dosn't reject mail for 
unknown local recipients


I've tried setting local_recipient_maps and 
unknown_local_recipient_reject_code = 550 - Nothing seems to help 
though... Anyone with some pointers as to where I should look for the error?


# postconf -n

alias_maps =
broken_sasl_auth_clients = yes
command_directory = /usr/local/sbin
config_directory = /usr/local/etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10026
daemon_directory = /usr/local/libexec/postfix
data_directory = /var/db/postfix
debug_peer_level = 2
html_directory = /usr/local/share/doc/postfix
in_flow_delay = 0
local_recipient_maps = 
proxy:pgsql:/usr/local/etc/postfix/local_recipient_maps

mail_owner = postfix
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
message_size_limit = 41943040
mydestination =
mynetworks = 10.10.10.0/24, 127.0.0.0/8
newaliases_path = /usr/local/bin/newaliases
proxy_interfaces = 194.255.69.21
proxy_read_maps = $local_recipient_maps $mydestination 
$virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps 
$virtual_mailbox_domains $relay_recipient_maps $relay_domains 
$canonical_maps $sender_canonical_maps $recipient_canonical_maps 
$relocated_maps $transport_maps $mynetworks $smtpd_sender_login_maps 
$smtp_sasl_password_maps

queue_directory = /var/spool/postfix
readme_directory = /usr/local/share/doc/postfix
relay_domains = proxy:pgsql:/usr/local/etc/postfix/relaydomainmap
relay_recipient_maps = proxy:pgsql:/usr/local/etc/postfix/relayaliasmap
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
smtpd_recipient_restrictions = permit_sasl_authenticated, 
permit_mynetworks, reject_unauth_destination, reject_unlisted_recipient

smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain = pixelpoint.dk
smtpd_sasl_path = smtpd
smtpd_sender_login_maps = proxy:pgsql:/usr/local/etc/postfix/saslmap
smtpd_tls_auth_only = no
smtpd_tls_cert_file = /usr/local/share/courier-imap/imapd.pem
smtpd_tls_key_file = /usr/local/share/courier-imap/imapd.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_use_tls = yes
transport_maps = proxy:pgsql:/usr/local/etc/postfix/mxmap
unknown_local_recipient_reject_code = 550
virtual_alias_maps = proxy:pgsql:/usr/local/etc/postfix/aliasmap
virtual_mailbox_domains = proxy:pgsql:/usr/local/etc/postfix/domainmap
virtual_transport = maildrop

master.cf:
#
# Postfix master process configuration file.  For details on the format
# of the file, see the master(5) manual page (command: man 5 master).
#
# ==
# service type  private unpriv  chroot  wakeup  maxproc command + args
#   (yes)   (yes)   (yes)   (never) (100)
# ==
smtp  inet  n   -   n   -   -   smtpd
  -o content_filter=smtp-amavis:[127.0.0.1]:10024
  -o smtp_send_xforward_command=yes
submission inet n   -   n   -   -   smtpd
#  -o smtpd_enforce_tls=yes
  -o smtpd_etrn_restrictions=reject
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o content_filter=smtp-amavis:[127.0.0.1]:10026
#smtps inet  n   -   n   -   -   smtpd
#  -o smtpd_tls_wrappermode=yes
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#628  inet  n   -   n   -   -   qmqpd
pickupfifo  n   -   n   60  1   pickup
cleanup   unix  n   -   n   -   0   cleanup
qmgr  fifo  n   -   n   300 1   qmgr
#qmgr fifo  n   -   n   300 1   oqmgr
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
# When relaying mail as backup MX, disable fallback_relay to avoid MX loops
relay unix  -   -   n   -   -   smtp
-o fallback_relay=
#   -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq unix  n   -   n   -   -   showq
error unix  -   -   n   -   -   error
retry unix  -   -  

Re: Problem with rejecting mail to unknown users

[Reindl Harald]

Am 01.02.2012 11:09, schrieb Martin Kruse Jensen:
 Hi.
 
 I'e got a problem I've been trying to solve for some time now, but I can't 
 seem to get it to work. I'm running
 Postfix on FreeBSD with Maildrop delivery, SASL authentification and 
 PostGreSQL backend. However I'm sending tons
 of backscatter because Postfix dosn't reject mail for unknown local recipients
 
 I've tried setting local_recipient_maps and 
 unknown_local_recipient_reject_code = 550 - Nothing seems to help
 though... Anyone with some pointers as to where I should look for the error?

 # postconf -n
 local_recipient_maps = proxy:pgsql:/usr/local/etc/postfix/local_recipient_maps

debug your local_recipient_maps

as long your configuration does not handle this correct
unknown_local_recipient_reject_code is not part of the
game because a) 550 is default and b) even if it would be
any other status-code - if you are rejecting then you
would not be a backscatter because you will never accept
the message



signature.asc
Description: OpenPGP digital signature

Re: Problem with rejecting mail to unknown users

[Martin Kruse Jensen]

Den 01-02-2012 11:48, Reindl Harald skrev:


Am 01.02.2012 11:09, schrieb Martin Kruse Jensen:

Hi.

I'e got a problem I've been trying to solve for some time now, but I can't seem 
to get it to work. I'm running
Postfix on FreeBSD with Maildrop delivery, SASL authentification and PostGreSQL 
backend. However I'm sending tons
of backscatter because Postfix dosn't reject mail for unknown local recipients

I've tried setting local_recipient_maps and unknown_local_recipient_reject_code 
= 550 - Nothing seems to help
though... Anyone with some pointers as to where I should look for the error?

# postconf -n
local_recipient_maps = proxy:pgsql:/usr/local/etc/postfix/local_recipient_maps

debug your local_recipient_maps

as long your configuration does not handle this correct
unknown_local_recipient_reject_code is not part of the
game because a) 550 is default and b) even if it would be
any other status-code -  if you are rejecting then you
would not be a backscatter because you will never accept
the message



Turns out all I needed was to set relay_recipient_maps - problem appears 
to be solved!

Re: Problem with rejecting mail to unknown users

[/dev/rob0]

On Wed, Feb 01, 2012 at 02:00:15PM +0100,
   Martin Kruse Jensen wrote:
 Turns out all I needed was to set relay_recipient_maps -
 problem appears to be solved!

Given the overall confusion of address classes in the postconf, 
including virtual_mailbox_domains being set without corresponding 
virtual_mailbox_maps, I am not at all confident that you have truly 
solved this. Sometimes relay_domains is set using the default of 
$mydestination

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

If further assistance is required, logs must be included:

http://www.postfix.org/DEBUG_README.html#mail
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if /dev/rob0 is in the Subject:

Unknown Users

[Jonathan Tripathy]

Hi Folks,

Does anyone know how to make a backup MX server query the primary mx server if 
a mailbox exsists, before accept the contents of the mail?

I have a problem with MAILER-DAEMON messages...

Thanks

Re: Unknown Users

[Eero Volotinen]

2010/2/11 Jonathan Tripathy jon...@abpni.co.uk:
 Hi Folks,

 Does anyone know how to make a backup MX server query the primary mx server
 if a mailbox exsists, before accept the contents of the mail?

 I have a problem with MAILER-DAEMON messages...

for example using address verification:
http://www.postfix.org/ADDRESS_VERIFICATION_README.html
 .. or keeping list of valid users on that machine..

--
Eero

Re: Unknown Users

[terry]

Quoting Jonathan Tripathy jon...@abpni.co.uk:


Hi Folks,

Does anyone know how to make a backup MX server query the primary mx  
server if a mailbox exsists, before accept the contents of the mail?


I have a problem with MAILER-DAEMON messages...

Thanks


That might not be the right problem to fix. If the primary mx is down,  
the backup mx might not have anything to query.


You might want to have the primary mx export a list of valid users  
periodically as a text file, then have the backup server pick it up  
with rsync, then postfix can use it to validate recipients.


Terry

Re: Unknown Users

[Jose Ildefonso Camargo Tolosa]

Greetings,

On Thu, Feb 11, 2010 at 10:11 AM,  te...@cnysupport.com wrote:
 Quoting Jonathan Tripathy jon...@abpni.co.uk:

 Hi Folks,

 Does anyone know how to make a backup MX server query the primary mx
 server if a mailbox exsists, before accept the contents of the mail?

 I have a problem with MAILER-DAEMON messages...

 Thanks

 That might not be the right problem to fix. If the primary mx is down, the
 backup mx might not have anything to query.

 You might want to have the primary mx export a list of valid users
 periodically as a text file, then have the backup server pick it up with
 rsync, then postfix can use it to validate recipients.

Or, maybe: integrate both MXs to *one* user database, like LDAP, or
*SQL, and have replication, then make the destination verification use
that database, if the primary MX is death, the secondary will still
have a valid, and up-to-date DB to verify its destinations.

I hope this helps,

Ildefonso Camargo

Forward mail to unknown users non virtual domain @domain.com to unkn...@domain com

[Михаил Евстратов]

*I have :*

Postfix - virual users in Openldap

Main.cf 
local_transport = maildrop
maildrop_destination_recipient_limit = 1
local_recipient_maps =

Master.cf 
maildrop unix - n n - - pipe
flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}

Openldap

Maildrop - non config files

Authlib

*I want:*

Forward mail to unknown users non virtual domain @domain.com to
unkn...@domain com

*Problem:*

I send mail te...@domain.com(absent user) , and maildrop
reject mail

Jul 24 11:01:25 gw postfix/pipe[19278]: 62A618D28C9: to=te...@domain.com,
re
lay=maildrop, delay=0.27, delays=0.14/0.01/0/0.13, dsn=5.1.1, status=bounced
(us
er unknown. Command output: Invalid user specified. )



How i fix this problem?

Thanks.

-- 
Mike Evstratov

Re: Rejecting email to unknown users at a virtual domain

[Wietse Venema]

Alan Boyd:
 Hello,
 
 I'm trying to find a way to reject email which is sent to an unknown  
 user (determined by an external program) at a virtual domain, such  
 that the email doesn't even enter the mail queue.
 
 Currently, my set up is as follows:
 I use a virtual mapping to send email in the format  
 [EMAIL PROTECTED] to a localuser.
 In my aliases file, email to localuser is piped to an external program  
 for delivery.
 
 I can set up my external program to return a sysexit code of 67 so  
 that a bounce message is sent back to the sender. But since I'm using  
 a catchall email address, this would result in a very large number of  
 bounce messages being sent due to the spammer 'shotgun' approach of  
 trying to find valid addresses. I'd much prefer it if I can find a way  
 to query the address early on so that an email to an unknown user is  
 rejected and doesn't even get in to the mail queue.
 
 Any clues on how this might be accomplished? I can change my external  
 program as desired and the 'valid' email addresses are variable (and  
 fairly large) but known.

For Postfix to reject invalid recipients at the SMTP port, this
information must be available as a lookup table. You will have
to use one of the supported database types: file, SQL, LDAP, and
so on, or add your own table lookup mechanism.

See man 1 postconf, option -m.

Wietse

Re: Rejecting email to unknown users at a virtual domain

[Alan Boyd]

Hi,

Thanks for the response. Two questions:

1) Which variable in main.cf should this lookup table be referenced in?
2) I've read the man page, but it isn't clear in whether I can  
reference a database or table which is produced as the output of a  
program? For example, whether postfix can read the output of some kind  
of generatetable.pl file?


Cheers!

On 26 Sep 2008, at 11:44, Wietse Venema wrote:


Alan Boyd:

Hello,

I'm trying to find a way to reject email which is sent to an unknown
user (determined by an external program) at a virtual domain, such
that the email doesn't even enter the mail queue.

Currently, my set up is as follows:
I use a virtual mapping to send email in the format
[EMAIL PROTECTED] to a localuser.
In my aliases file, email to localuser is piped to an external  
program

for delivery.

I can set up my external program to return a sysexit code of 67 so
that a bounce message is sent back to the sender. But since I'm using
a catchall email address, this would result in a very large number of
bounce messages being sent due to the spammer 'shotgun' approach of
trying to find valid addresses. I'd much prefer it if I can find a  
way

to query the address early on so that an email to an unknown user is
rejected and doesn't even get in to the mail queue.

Any clues on how this might be accomplished? I can change my external
program as desired and the 'valid' email addresses are variable (and
fairly large) but known.


For Postfix to reject invalid recipients at the SMTP port, this
information must be available as a lookup table. You will have
to use one of the supported database types: file, SQL, LDAP, and
so on, or add your own table lookup mechanism.

See man 1 postconf, option -m.

Wietse

Re: Rejecting email to unknown users at a virtual domain

[mouss]

Alan Boyd wrote:

Gah.

I was hoping there'd be some means to do a simple pipe to an external 
application which provided the result. :(
I suppose the SMTPD_POLICY_README is the way to go, then. Though it's a 
little more heavyweight than I anticipated.


Still, it would allow me to easily ignore other domains



if you don't use a catchall or don't rbeak address validation with 
wildcard virtual aliases, postfix would reject invalid recipients.


but since you're apparently breaking that, you need to reject recipients 
you don't want to accept either using a policy service or a map 
(check_recipient_access...).