Re: Question regarding smtpd and log of “Untrusted TLS connection”

[Viktor Dukhovni]

> On Oct 20, 2017, at 4:54 PM, J Doe  wrote:
> 
> I currently have a Postfix 3.1.0 server with smtpd configured to use
> opportunistic TLS encryption:
> 
>/etc/postfix/main.cf
>smtpd_tls_security_level = may

This setting is for inbound mail from remote servers to you.

> In the documentation I have noted that even if STARTTLS is enabled, mail
> delivery will not be stopped even if the certificate at the other server
> is invalid or is a self-signed certificate. As such, TLS encryption is
> used but authentication of the remote server does not happen.

Now you've switched to talking to about outbound mail (delivery from
your system to other systems).

> I have noticed in my logs today an entry:
> 
>postfix/smtpd[1234]: Untrusted TLS connection established from 
> example.com[1.2.3.4]: TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 
> bits)
> 
> ...where example.com is not the real server name.

And now you're looking at inbound mail again, and it seems that you've
enabled receipt of client certificates, which is generally not a good
idea on port 25 (the default is smtpd_tls_ask_ccert = no).

> When smtpd parsed the certificate before this log entry, I noticed that
> the subject_CN of the certificate is the same as the issuer - for example:
> 
>subject_CN=example
>issuer=example
> 
> ...where example is not a FQDN but the hostname of the remote server.
> There is also no references to certificate authorities.

Perfectly normal even for receiving server, but escpecially for SMTP
client certificates CA-issued names are not especially meaningful.
What would you do differently on port 25 when receiving inbound mail
from a client with a given certificate?

More generally, see:

http://www.postfix.org/TLS_README.html#client_tls_limits

> I am wondering two things:
> 
> [1] Am I correct that the remote server has not been authenticated but
> has used encryption ?

The transmission channel is encrypted all the way from the remote
server to any TLS man in the middle attacker, and again all the
way from the man in the middle attacker to you. :-)

More seriously, the channel is immune to passive wiretaps, but
unless the client authenticated your server somehow, and would
not have continued sans authenticated TLS, MiTM attacks cannot
be excluded.

> [2] Is it not authenticated in this case because the remote server
> appears to be a self-signed certificate ?

You're still confusing the sending and receiving sides...

-- 
Viktor.

Re: Question regarding smtpd and log of “Untrusted TLS connection”

[Noel Jones]

On 10/20/2017 3:54 PM, J Doe wrote:
> I am wondering two things:
> 
> [1] Am I correct that the remote server has not been authenticated but has 
> used encryption ?
> 

Correct.

> [2] Is it not authenticated in this case because the remote server appears to 
> be a self-signed certificate ?
> 

No certificate is exchanged; all connections are unauthenticated.



  -- Noel Jones

Re: Virtual Domains/ Users

[Noel Jones]

On 10/20/2017 12:42 PM, cac...@quantum-equities.com wrote:
> Thanks Noel and Rob, I may be on the right track now.  Good to know
> I can trust the docs to be current.
> 
> So my three domains with 6 users are completely independent of one
> another;  no aliasing.  Thus I used
> *Non-Postfix mailbox store: separate domains, non-UNIX accounts*
> 
> In main.cf I set mydomain to the main domain, example1.com. 

That's fine.  "mydomain" is the internet domain of your host and not
necessarily a mail destination.

> Should
> that instead be mail.example1.com? 

You can use that as myhostname, which is the internet name of your
computer.

mydestination should  be set empty or set to localhost.

mydestination = localhost

> If so, where else should I set
> mail.example1.com?  In my registrar, or in the mail system,
> example1.com, or nothing?
> 
> And I set virtual_mailbox_domains = example2.com example3.com

You should also list example1.com in virtual_mailbox_domains.

> 
> In /etc/postfix/vmailbox I set:
>     us...@example1.com                ex1.com/user1
>     us...@example1.com    ex1.com/user2
>     r...@example1.com                  ex1.com@root
> 
>     us...@example2.com    ex2.com/user3
>     us...@example2.com    ex2.com/user4
> 
>     us...@example3.com        ex3.com/user5
>     us...@example3.com        ex3.com/user6
> 
> Is this right?  Should $mydomain users be in the vmailbox file?  If
> not, where?
> 
> In /etc/postfix/virtual ( have
>     # Redirect system email so it can be picked up
>     root    r...@quantum-equities.com
> 
> Will this bypass /var/spool/mail/root and send it directly to
> /var/spool/mail/vhosts/ex1.com/root so it can be picked up?
> 
> Am I right that the users in /var/spool/mail/vhosts/ex?/ must be
> text files and not directories (since I don't add / for maildir format)?
> 
> Is setting a group of 'mail' down the /var/spool/mail/vhosts/ line
> adequate for everything to function properly, including pickup
> through Dovecot?
> 
> Man, email ain't suited to the ill or weak of mind or will...
> 
> 
> 

Question regarding smtpd and log of “Untrusted TLS connection”

[J Doe]

Hello,

I currently have a Postfix 3.1.0 server with smtpd configured to use 
opportunistic TLS encryption:

/etc/postfix/main.cf
smtpd_tls_security_level = may

In the documentation I have noted that even if STARTTLS is enabled, mail 
delivery will not be stopped even if the certificate at the other server is 
invalid or is a self-signed certificate.  As such, TLS encryption is used but 
authentication of the remote server does not happen.

I have noticed in my logs today an entry:

postfix/smtpd[1234]: Untrusted TLS connection established from 
example.com[1.2.3.4]: TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)

...where example.com is not the real server name.

When smtpd parsed the certificate before this log entry, I noticed that the 
subject_CN of the certificate is the same as the issuer - for example:

subject_CN=example
issuer=example

...where example is not a FQDN but the hostname of the remote server.  There is 
also no references to certificate authorities.

I am wondering two things:

[1] Am I correct that the remote server has not been authenticated but has used 
encryption ?

[2] Is it not authenticated in this case because the remote server appears to 
be a self-signed certificate ?

Thanks,

- J

Re: How can I "reject_unverified_LOCAL_sender"?

[Rick van Rein]

Ah!

>> I don't see how I can do this with Postfix, and it's not even simple in
>> a policy due to the cyclic risk.  What are others doing in this respect?
>
> /etc/postfix/main.cf
> smtpd_reject_unlisted_sender = yes

I mistook the documentation of this option to also work on external senders!

Thanks,
 -Rick

Re: How can I "reject_unverified_LOCAL_sender"?

[Philip Paeps]

On 2017-10-20 21:28:29 (+0200), Rick van Rein wrote:

On 2017-10-20 21:17:26 (+0200), Philip Paeps wrote:

On 2017-10-20 19:51:07 (+0200), Rick van Rein wrote:


Wouldn't it be a lot easier simply to reject those with SPF?  If 
you're seeing mail from one of your domains coming in from a host you 
know couldn't have legitimately sent it, you can reject it outright.


That would block not just the spam, but also legitimate bypassing 
through forwarders and email lists (if they don't do VERP).  I would 
prefer not to go there for something that could be solved with local 
information.


It would break legitimate forwarders, but that's easy to whitelist 
because (hopefully) you know your forwarders.  The salient part of my 
configuration is:


   smtpd_sender_restrictions =
   permit_mynetworks
   reject_unknown_sender_domain
   check_client_access cidr:$config_directory/access_client.cidr
   check_client_access hash:$config_directory/access_forwarders
   check_recipient_access pcre:$config_directory/access_recipient.pcre
   check_spf

The `access_forwarders` table lists all legitimate forwarders.  There 
are a couple of forwarders in `access_recipient` too: forwarders whose 
IP addresses I can't (easily) control, I configure to forward to a 
unique (and opaque and non-guessable) alias.


But SPF does rely on information that is not local (to Postfix).

If you don't want to use SPF, you could use a combination of a 
check_client_access to whitelist your hosts followed by a 
check_sender_access.


That's a neat work-around.  It hinges on not having any checks or 
rejects after these ones, but for the sender_restrictions, that is 
currently true.


Since there's not all that much you can check in sender restrictions, 
that shouldn't be a big problem.  You may be able to fiddle with (not) 
deferring reject if that's a limitation for you.


If you don't want to rely on SPF, you should be able to modify my 
configuration by adding a `check_sender_access` after the whitelists.


One way to go could be to create a database of sender domains to 
validate, enter my own domains in it, and use "external" access to my 
own MTA and probing it.  But that leads to cyclic probing!  I suppose 
I am really looking for something simpler -- namely an invocation of 
the virtual(8) server for addresses on the said lists.


Why bother validating the address?


Because that is the vital piece of information that sets the attempts 
by spammers aside from proper behaviour.  Because that gives a good 
source for detecting, with high degree of certainty, that a party is 
sending spam.


If you really have no control over your forwarders, this is true.

It may be worth the effort to take control over the forwarders though.  
SPF blocks a lot of crap.  As I wrote: the forwarders you know by IP 
address can simply be a check_client_access.  Forwarders whose IP 
addresses are variable can hopefully be taught to forward to a unique 
address.


For bootstrapping new restrictions, I find `warn_if_reject` extremely 
helpful.


Good luck.

Philip

--
Philip Paeps
Senior Reality Engineer
Ministry of Information

Re: How can I "reject_unverified_LOCAL_sender"?

[Wietse Venema]

Rick van Rein:
> Hello,
> 
> I see a lot of spam entering that claims to have come from a local
> domain, usually guessing a non-existent account.  I've been looking for
> a way to "reject_unverified_local_sender", by which I mean that the
> sender address is verified iff it occurs in virtual_alias_domains (and
> perhaps a few other lists).
> 
> One way to go could be to create a database of sender domains to
> validate, enter my own domains in it, and use "external" access to my
> own MTA and probing it.  But that leads to cyclic probing!  I suppose I
> am really looking for something simpler -- namely an invocation of the
> virtual(8) server for addresses on the said lists.
> 
> I don't see how I can do this with Postfix, and it's not even simple in
> a policy due to the cyclic risk.  What are others doing in this respect?

/etc/postfix/main.cf
smtpd_reject_unlisted_sender = yes

That will reject MAIL FROM commands with a non-existent local sender.

Wietse

Re: How can I "reject_unverified_LOCAL_sender"?

[Rick van Rein]

Hi Philip,

> Wouldn't it be a lot easier simply to reject those with SPF?  If
> you're seeing mail from one of your domains coming in from a host you
> know couldn't have legitimately sent it, you can reject it outright.

That would block not just the spam, but also legitimate bypassing
through forwarders and email lists (if they don't do VERP).  I would
prefer not to go there for something that could be solved with local
information.
>
> If you don't want to use SPF, you could use a combination of a
> check_client_access to whitelist your hosts followed by a
> check_sender_access.
>
That's a neat work-around.  It hinges on not having any checks or
rejects after these ones, but for the sender_restrictions, that is
currently true.

>> One way to go could be to create a database of sender domains to
>> validate, enter my own domains in it, and use "external" access to my
>> own MTA and probing it.  But that leads to cyclic probing!  I suppose
>> I am really looking for something simpler -- namely an invocation of
>> the virtual(8) server for addresses on the said lists.
>
> Why bother validating the address?

Because that is the vital piece of information that sets the attempts by
spammers aside from proper behaviour.  Because that gives a good source
for detecting, with high degree of certainty, that a party is sending spam.

>
>> I don't see how I can do this with Postfix, and it's not even simple
>> in a policy due to the cyclic risk.  What are others doing in this
>> respect?

Thanks, for your input Phil!

-Rick

Re: How can I "reject_unverified_LOCAL_sender"?

[Philip Paeps]

On 2017-10-20 19:51:07 (+0200), Rick van Rein wrote:
I see a lot of spam entering that claims to have come from a local 
domain, usually guessing a non-existent account.  I've been looking for 
a way to "reject_unverified_local_sender", by which I mean that the 
sender address is verified iff it occurs in virtual_alias_domains (and 
perhaps a few other lists).


Wouldn't it be a lot easier simply to reject those with SPF?  If you're 
seeing mail from one of your domains coming in from a host you know 
couldn't have legitimately sent it, you can reject it outright.


If you don't want to use SPF, you could use a combination of a 
check_client_access to whitelist your hosts followed by a 
check_sender_access.


One way to go could be to create a database of sender domains to 
validate, enter my own domains in it, and use "external" access to my 
own MTA and probing it.  But that leads to cyclic probing!  I suppose I 
am really looking for something simpler -- namely an invocation of the 
virtual(8) server for addresses on the said lists.


Why bother validating the address?

I don't see how I can do this with Postfix, and it's not even simple in 
a policy due to the cyclic risk.  What are others doing in this 
respect?


I use SPF.

Philip

--
Philip Paeps
Senior Reality Engineer
Ministry of Information

Re: Block IP rcpt-to or block MX

[Emanuel]

Thanks for your help.


El 20/10/17 a las 11:06, Dominic Raferd escribió:
On 20 October 2017 at 14:50, Emanuel > wrote:


Quota: *Obvs you need to hash the transport file and then reload
postfix. This transport file can easily be extended to cover
similar cases.*

how to make this?

​
postmap /etc/postfix/transport
postfix reload​



--
envialosimple.com   
Emanuel Gonzalez
Deliverability Specialist
emanuel.gonza...@donweb.com 
www.envialosimple.com 
by donweb 

Nota de confidencialidad: Este mensaje y archivos adjuntos al mismo son 
confidenciales, de uso exclusivo para el destinatario del mismo. La 
divulgación y/o uso del mismo sin autorización por parte de DonWeb.com 
queda prohibida.
DonWeb.com no se hace responsable del mensaje por la falsificación y/o 
alteración del mismo.
De no ser Ud el destinatario del mismo y lo ha recibido por error, por 
favor, notifique al remitente y elimínelo de su sistema.
Confidentiality Note: This message and any attachments (the message) are 
confidential and intended solely for the addressees. Any unauthorised 
use or dissemination is prohibited by DonWeb.com.

DonWeb.com shall not be liable  for the message if altered or falsified.
If you are not the intended addressee of this message, please cancel it 
immediately and inform the sender
Nota de Confidencialidade: Esta mensagem e seus eventuais anexos podem 
conter dados confidenciais ou privilegiados.
Se você os recebeu por engano ou não é um dos destinatários aos quais 
ela foi endereçada, por favor destrua-a e a todos os seus eventuais 
anexos ou copias realizadas, imediatamente.
É proibida a retenção, distribuição, divulgação ou utilização de 
quaisquer informações aqui contidas.
Por favor, informenos sobre o recebimento indevido desta mensagem, 
retornando-a para o autor.

Re: Block IP rcpt-to or block MX

[Bill Cole]

On 20 Oct 2017, at 12:25 (-0400), Matus UHLAR - fantomas wrote:


On 20 Oct 2017, at 9:38 (-0400), Matus UHLAR - fantomas wrote:
unless you know that hotmial.com is an malicious site, don't block 
it.


On 20.10.17 10:43, Bill Cole wrote:
Go to http://hotmial.com with a JavaScript-enabled browser and tell 
me what you think.


Or, DON'T DO THAT!

At least, don't do it on a weakly-defended system. I give you my 
word: it IS a malicious site.


then I really wonder why it's not listed in domain blacklist (just 
searched

through blacklistalert and mxtoolbox)


You'd have to ask the people who maintain those blacklists, but my first 
guess would be that it is an entirely passive malicious domain, slurping 
up mail and web hits from typos.


The web site redirects hits using JavaScript, with the initial reply 
varying based on User-Agent. After the 3rd such redirection it pops up a 
bogus warning frame claiming to be alerting the user to a backdoor 
trojan infection that can only be removed by calling a phone number, and 
asserting that if the user fails to do so, their Internet access will be 
blocked.


If you hit the site with curl, wget, or no User-Agent header, it yields 
a simple "403 Forbidden" response, which is what provider-nuked sites 
often do. It may be that domain blacklists intended for email usage are 
blind to the existence of the domain because it does not appear in spam, 
they may be fooled by the fact that the website is playing dead to 
simple web clients, or it may be that some blacklists intended for email 
intentionally avoid listing domains that are known bad but never show up 
in spam.



in those cases reject_rhsbl_recipient should do the job.

However my recommendation was generic:

don't block domains only because your users mistype.


Yes.


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

How can I "reject_unverified_LOCAL_sender"?

[Rick van Rein]

Hello,

I see a lot of spam entering that claims to have come from a local
domain, usually guessing a non-existent account.  I've been looking for
a way to "reject_unverified_local_sender", by which I mean that the
sender address is verified iff it occurs in virtual_alias_domains (and
perhaps a few other lists).

One way to go could be to create a database of sender domains to
validate, enter my own domains in it, and use "external" access to my
own MTA and probing it.  But that leads to cyclic probing!  I suppose I
am really looking for something simpler -- namely an invocation of the
virtual(8) server for addresses on the said lists.

I don't see how I can do this with Postfix, and it's not even simple in
a policy due to the cyclic risk.  What are others doing in this respect?

Thanks,
 -Rick

Re: Virtual Domains/ Users

[cacook]

Thanks Noel and Rob, I may be on the right track now.  Good to know I
can trust the docs to be current.

So my three domains with 6 users are completely independent of one
another;  no aliasing.  Thus I used
*Non-Postfix mailbox store: separate domains, non-UNIX accounts*

In main.cf I set mydomain to the main domain, example1.com.  Should that
instead be mail.example1.com?  If so, where else should I set
mail.example1.com?  In my registrar, or in the mail system,
example1.com, or nothing?

And I set virtual_mailbox_domains = example2.com example3.com

In /etc/postfix/vmailbox I set:
    us...@example1.com                ex1.com/user1
    us...@example1.com    ex1.com/user2
    r...@example1.com                  ex1.com@root

    us...@example2.com    ex2.com/user3
    us...@example2.com    ex2.com/user4

    us...@example3.com        ex3.com/user5
    us...@example3.com        ex3.com/user6

Is this right?  Should $mydomain users be in the vmailbox file?  If not,
where?

In /etc/postfix/virtual ( have
    # Redirect system email so it can be picked up
    root    r...@quantum-equities.com

Will this bypass /var/spool/mail/root and send it directly to
/var/spool/mail/vhosts/ex1.com/root so it can be picked up?

Am I right that the users in /var/spool/mail/vhosts/ex?/ must be text
files and not directories (since I don't add / for maildir format)?

Is setting a group of 'mail' down the /var/spool/mail/vhosts/ line
adequate for everything to function properly, including pickup through
Dovecot?

Man, email ain't suited to the ill or weak of mind or will...





0x946C680E.asc
Description: application/pgp-keys

Re: noobie configuration problem

[S McGraw]

I had glanced at the transport(5) man page previously but when I saw 
the "nexthop" notations, presumed I could only specify a single machine 
there.  I see now I was wrong.  Thanks and thanks also to Raimund Sacherer.

On 10/18/2017 09:15 PM, Anvar Kuchkartaev wrote:
> Take a look at:
> http://www.postfix.org/transport.5.html
> ‎http://postfix.1071664.n5.nabble.com/Postfix-Relayhost-exemptions-td43587.html
> 
> Anvar Kuchkartaev 
> an...@anvartay.com
> 
>   Original Message  
>> From: S McGraw
>> I want what must be a very common mail arrangement that I can seem to
>> make work...
>> 
>> I have a local network with a "fake" domain name (.home) with several
>> machines, each with postfix. I want any machine, say x.home, to be able
>> to send to any other other machine, say y.home, directly. Any mail
>> not addressed to a .home machine (and not for local delivery) I want 
>> to go my gmail relayhost.
>> 
>> The problem is that .home mail goes to the relay host rather than the 
>> intended machine.
>> [...]

easy DKIM question, at least i think it is...

[Fazzina, Angelo]

Hi, i have a small DKIM question.   config files are at bottom of email.
I got it working but don't understand why ?

The one change i made to get it to work was add
137.99.0.0/16 to the TrustedHosts file.

So  tests with from of  x...@appmail.uconn.edu and x...@uconn.edu are getting 
signed and I see it in the Postfix logs.


My question:
my prod servers(3 of them)  smtp.uconn.edu allow authenticated users to send 
over 465 and 587.
So they could come from any IP address in the world.
I assume all users are using a from address of x...@uconn.edu or  
x...@yyy.uconn.edu.
Is it possible to get emails signed with DKIM ?



These are the 3 files i configured
SigningTable =
*@appmail.uconn.edu dkim1._domainkey.mta4.uits.uconn.edu
*@uconn.edu dkim1._domainkey.mta4.uits.uconn.edu
*@uits.uconn.edu dkim1._domainkey.mta4.uits.uconn.edu

KeyTable =
dkim1._domainkey.mta4.uits.uconn.edu 
mta4.uits.uconn.edu:dkim1:/etc/opendkim/keys/uconn/dkim1.private

TrustedHosts = 
127.0.0.1
137.99.0.0/16
::1

This is the opendkim.conf file =

PidFile /var/run/opendkim/opendkim.pid
Modesv
Syslog  yes
SyslogSuccess   yes
LogWhy  yes
UserID  opendkim:opendkim
Socket  inet:8891@localhost
Umask   002
SendReports yes
ReportAddress   "UITS-SSG OpenDKIM" 
SoftwareHeader  yes
Canonicalizationrelaxed/simple
Selectordkim1
MinimumKeyBits  1024
KeyTable/etc/opendkim/KeyTable
SigningTablerefile:/etc/opendkim/SigningTable
ExternalIgnoreList  refile:/etc/opendkim/TrustedHosts
InternalHosts   refile:/etc/opendkim/TrustedHosts

-ANGELO FAZZINA

UITS Service Manager:
Spam and Virus Prevention
Mass Mailing
G Suite/Gmail

ang...@uconn.edu
University of Connecticut,  UITS, SSG, Server Systems
860-486-9075

Re: Block IP rcpt-to or block MX

[Matus UHLAR - fantomas]

On 20 Oct 2017, at 9:38 (-0400), Matus UHLAR - fantomas wrote:

unless you know that hotmial.com is an malicious site, don't block it.


On 20.10.17 10:43, Bill Cole wrote:
Go to http://hotmial.com with a JavaScript-enabled browser and tell 
me what you think.


Or, DON'T DO THAT!

At least, don't do it on a weakly-defended system. I give you my 
word: it IS a malicious site.


then I really wonder why it's not listed in domain blacklist (just searched
through blacklistalert and mxtoolbox)

in those cases reject_rhsbl_recipient should do the job.

However my recommendation was generic:

don't block domains only because your users mistype.
--
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.
There's a long-standing bug relating to the x86 architecture that
allows you to install Windows.   -- Matthew D. Fuller

Re: disable receiving for particular email

[Bill Cole]

On 20 Oct 2017, at 11:37 (-0400), Michael Orlitzky wrote:


tl;dr use a real address


That's the bottom line best practice for all use cases. ALL.

If you can't think of a process to handle the asynchronous bounces and 
the intentional replies by innocent fools, you should not be sending the 
email. Make the SMTP envelope sender an address that works so that you 
know (or automatically deal with) the inevitable cases when a target 
address goes bad. Add a Reply-To header with a role address that a real 
human or one of a group of humans will read at least daily, to handle 
the clueless human issues.


This isn't really hard, unless you're trying to escape responsibility 
for the mail you send. That's actually very hard, because if people want 
it to stop, they'll find ways to keep it out and maybe impair your 
general ability to send to others.


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

Re: disable receiving for particular email

[Ralph Seichter]

On 20.10.2017 17:37, Michael Orlitzky wrote:

> [...]
> tl;dr use a real address

The reply address is "real", just not monitored. The people I work with
who receive this type of message are smart enough to contact a human, so
I can in good conscience use nore...@somedomain.tld as a generic sender
address and not bother with matching that address to whatever person may
or may not be responsible a month from now. If you choose a different
policy, then so be it, but stating that a sinkhole address is always a
bad thing to have is factually incorrect.

-Ralph

Re: disable receiving for particular email

[Michael Orlitzky]

On 10/20/2017 09:57 AM, Ralph Seichter wrote:
> 
> Depending on the use case, discarding email can be as valid a method as
> rejecting email. Messages sent by automation- or monitoring-services
> (Jenkins, Icinga) come to mind. If somebody chooses to reply to these
> machine-generated notifications, I expect him to manually select a human
> recipient, or the reply will be silently ignored.
> 

You don't want to send Nagios alerts to someone who keeps replying "YOU
HAVE THE WRONG PHONE NUMBER."

You don't want to send Jenkins reports to an email address that has been
dead since Dave quit five years ago.

If one of your coworkers who apparently has something important to
communicate hits "reply" on a build failure, I'm not sure how silently
ignoring him is better than responding with "I think you meant to send
this to the Jenkins admin."

tl;dr use a real address

Re: Block IP rcpt-to or block MX

[Bill Cole]

On 20 Oct 2017, at 9:38 (-0400), Matus UHLAR - fantomas wrote:


unless you know that hotmial.com is an malicious site, don't block it.


Go to http://hotmial.com with a JavaScript-enabled browser and tell me 
what you think.


Or, DON'T DO THAT!

At least, don't do it on a weakly-defended system. I give you my word: 
it IS a malicious site.


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

Re: Block IP rcpt-to or block MX

[/dev/rob0]

On Fri, Oct 20, 2017 at 03:06:32PM +0100, Dominic Raferd wrote:
> On 20 October 2017 at 14:50, Emanuel
>  wrote:
> 
> > Quota: *Obvs you need to hash the transport file and then reload 
> > postfix. This transport file can easily be extended to cover 
> > similar cases.*
> >
> > how to make this?
> ​
> postmap /etc/postfix/transport
> postfix reload​

The reload is not necessary after the postmap command.  A reload 
speeds things up for configuration changes or for changes in in- 
memory map types.  For hash: maps, no.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: filter_readme nexthop lookup

[Luca Cazzaniga]

Thanks for your answer Mr Venema.
In the readme they define the service on the port 10025 directly in the
master.cf using the spawn utility, maybe the smtp agent doesn't lookup a
dns record if it finds the next host defined in the service column of
master.cf. Unfortunately now I'm in the office and I have to wait to have
further fun with postfix but the smtp_host_lookup will surely solve the
problem.

Regards

Luca



On 20 October 2017 at 15:43, Wietse Venema  wrote:

> fusillator:
> > Does FILTER_README suppose you have a dns record for localhost?
> > Is there a way to use /etc/hosts to resolve localhost?
>
> FILTER_README does none of that. It just describes how you use a
> Postfix SMTP client (or other Postfix delivery agent) to send mail
> into a filter, and how to get that mail back into Postfix.
>
> In other words, if your SMTP client can't deliver to localhost,
> then that has nothing to do with content filtering.
>
> By default (smtp_host_lookup = dns) the SMTP client uses DNS to
> look up destinations. You can change that; see
> http://www.postfix.org/postconf.5.html#smtp_host_lookup
>
> Wietse
>

Re: Block IP rcpt-to or block MX

[Dominic Raferd]

On 20 October 2017 at 14:50, Emanuel  wrote:

> Quota: *Obvs you need to hash the transport file and then reload postfix.
> This transport file can easily be extended to cover similar cases.*
>
> how to make this?
>
​
postmap /etc/postfix/transport
postfix reload​

Re: disable receiving for particular email

[Ralph Seichter]

On 20.10.2017 14:43, /dev/rob0 wrote:

> On Fri, Oct 20, 2017 at 11:12:17AM +0200, Matus UHLAR - fantomas wrote:
>
> > I recommend using real, existent address and check its content once
> > upon a time. You don't want to get blocked (see points 2. and 4.)
>
> Absolutely. This is better than the DISCARD suggestion. I find that
> people who ask for "do not reply" addresses usually don't understand
> what they are asking for, nor what they will get when they have it.

Depending on the use case, discarding email can be as valid a method as
rejecting email. Messages sent by automation- or monitoring-services
(Jenkins, Icinga) come to mind. If somebody chooses to reply to these
machine-generated notifications, I expect him to manually select a human
recipient, or the reply will be silently ignored.

-Ralph

Re: disable receiving for particular email

[/dev/rob0]

On Fri, Oct 20, 2017 at 03:29:02PM +0200, Poliman - Serwis wrote:
> Do you have maybe other better options? I am open for all nice 
> suggestions. :)

I already said what I think is best, so no.  But maybe we don't fully 
know why you're wanting the "no reply" address?

> 2017-10-20 14:43 GMT+02:00 /dev/rob0 :
> 
> > On Fri, Oct 20, 2017 at 11:12:17AM +0200,
> >Matus UHLAR - fantomas wrote:
> > > I recommend using real, existent address and check its content 
> > > once upon a time. You don't want to get blocked (see points 2. 
> > > and 4.)
> >
> > Absolutely.  This is better than the DISCARD suggestion.  I find 
> > that people who ask for "do not reply" addresses usually don't 
> > understand what they are asking for, nor what they will get when 
> > they have it.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: filter_readme nexthop lookup

[Wietse Venema]

fusillator:
> Does FILTER_README suppose you have a dns record for localhost?
> Is there a way to use /etc/hosts to resolve localhost?

FILTER_README does none of that. It just describes how you use a
Postfix SMTP client (or other Postfix delivery agent) to send mail
into a filter, and how to get that mail back into Postfix.

In other words, if your SMTP client can't deliver to localhost,
then that has nothing to do with content filtering.

By default (smtp_host_lookup = dns) the SMTP client uses DNS to
look up destinations. You can change that; see
http://www.postfix.org/postconf.5.html#smtp_host_lookup

Wietse

Re: Block IP rcpt-to or block MX

[Matus UHLAR - fantomas]

On 20.10.17 10:21, Emanuel wrote:
Is it possible to create a list where the IP of certain recipients 
can be blocked?


IPs not, domains yes, use check_recipient_access
http://www.postfix.org/SMTPD_ACCESS_README.html


Our users incorrectly type the domain name of the recipient.

*hotmial.com ==> hotmail.com*

My idea is block the MX or IP ==> mail.h-email.net - 198.133.159.122


unless you know that hotmial.com is an malicious site, don't block it.

--
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.
"Two words: Windows survives." - Craig Mundie, Microsoft senior strategist
"So does syphillis. Good thing we have penicillin." - Matthew Alton

Re: Block IP rcpt-to or block MX

[Dominic Raferd]

On 20 October 2017 at 14:21, Emanuel  wrote:

> Hello,
>
> Is it possible to create a list where the IP of certain recipients can be
> blocked?
>
> Here and example:
>
> Oct 19 10:15:09 smtp01 postfix/smtpd[11048]: 5C28C20018459:
> client=myserver[172.17.111.242]
> Oct 19 10:15:09 smtp01 postfix/cleanup[6836]: 5C28C20018459: message-id=
> <59e8a0ca77...@domain.com> <59e8a0ca77...@domain.com>
> Oct 19 10:15:09 smtp01 postfix/qmgr[3054]: 5C28C20018459: from=
>  , size=16981, nrcpt=1 (queue active)
> Oct 19 10:15:25 smtp01 smht-101-41/smtp[7698]: 5C28C20018459: to=
>  , 
> relay=mail.h-email.net[198.133.159.122]:25,
> delay=16, delays=0.15/0/9.2/6.3, dsn=2.0.0, status=sent (250 Queued!)
> Oct 19 10:15:25 smtp01 postfix/qmgr[3054]: 5C28C20018459: removed
>
> Our users incorrectly type the domain name of the recipient.
>
> *hotmial.com  ==> hotmail.com *
>
> My idea is block the MX or IP ==> mail.h-email.net - 198.133.159.122
>

​A better idea is to block the sending by recipient domain, with a suitable
warning:

/etc/postfixmain.cf:

transport_maps = hash:/etc/postfix/transport


/etc/postfix/transport:
hotmial.com error:5.1.2 maybe you mean hotmail.com
hotmal.com error:5.1.2 maybe you mean hotmail.com
hoitmail.com error:5.1.2 maybe you mean hotmail.com
homail.com error:5.1.2 maybe you mean hotmail.com
hotrmail.com error:5.1.2 maybe you mean hotmail.com
hotmil.com error:5.1.2 maybe you mean hotmail.com
hotmaill.com error:5.1.2 maybe you mean hotmail.com


Obvs you need to hash the transport file and then reload postfix. This
transport file can easily be extended to cover similar cases.

Re: disable receiving for particular email

[Matus UHLAR - fantomas]

On Fri, Oct 20, 2017 at 11:12:17AM +0200,
   Matus UHLAR - fantomas wrote:
> I recommend using real, existent address and check its content once
> upon a time. You don't want to get blocked (see points 2. and 4.)



2017-10-20 14:43 GMT+02:00 /dev/rob0 :

Absolutely.  This is better than the DISCARD suggestion.  I find that
people who ask for "do not reply" addresses usually don't understand
what they are asking for, nor what they will get when they have it.


On 20.10.17 15:29, Poliman - Serwis wrote:

Do you have maybe other better options? I am open for all nice suggestions.


this one is the best option. Unless you want to face results below


> note that:
> 1. anyone doing address verification will block the address
> 2. systems that block senders who mail nonexistent addresses will block you
>you won't find out you mail nonexistent addresses after mail leaves your
>server, since you reject bounces to that addresses
> 3. anyone getting angry for sending mail from nonexistent address will
>block the address manually
> 4. anyone getting angry for sending mail from nonexistent address may block
>you manually.


--
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.
Emacs is a complicated operating system without good text editor.

Re: disable receiving for particular email

[Richard]

What are you really trying to accomplish? What is the problem you are
trying to solve?



 Original Message 
> Date: Friday, October 20, 2017 15:29:02 +0200
> From: Poliman - Serwis 
> To: Postfix users 
> Subject: Re: disable receiving for particular email
>
> Do you have maybe other better options? I am open for all nice
> suggestions. :)
> 
> 2017-10-20 14:43 GMT+02:00 /dev/rob0 :
> 
>> On Fri, Oct 20, 2017 at 11:12:17AM +0200,
>>Matus UHLAR - fantomas wrote:
>> > On 20.10.17 08:00, Poliman - Serwis wrote:
>> > > Hi all. I would like to create "do not reply" email account.
>> > > The simpliest way is create an email account and disable
>> > > receiving.
>> 
>> As was suggested upthread, the simplest way is NOT to create the
>> account.
>> 
>> > > Which option in Postfix permit disable receiving for particular
>> > > email?
>> > 
>> > you can disable receiving mail for such account using
>> > check_recipient_access
>> 
>> Some references of interest:
>> http://www.postfix.org/SMTPD_ACCESS_README.html
>> http://www.postfix.org/postconf.5.html#check_recipient_access
>> http://www.postfix.org/access.5.html
>> 
>> > note that:
>> > 1. anyone doing address verification will block the address
>> > 2. systems that block senders who mail nonexistent addresses
>> > will block
>> you
>> >you won't find out you mail nonexistent addresses after mail
>> >leaves
>> your
>> >server, since you reject bounces to that addresses
>> > 3. anyone getting angry for sending mail from nonexistent
>> > address will block the address manually
>> > 4. anyone getting angry for sending mail from nonexistent
>> > address may
>> block
>> >you manually.
>> > 
>> > I recommend using real, existent address and check its content
>> > once upon a time. You don't want to get blocked (see points 2.
>> > and 4.)
>> 
>> Absolutely.  This is better than the DISCARD suggestion.  I find
>> that people who ask for "do not reply" addresses usually don't
>> understand what they are asking for, nor what they will get when
>> they have it. --
>>   http://rob0.nodns4.us/
>>   Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

 End Original Message 

Re: Tailored filter

[Seb]

Hello,


Thanks a lot Noel for this bird's-eye view of possible solutions. The most 
promising tool for my setting seems to be Postfwd, which I'll now explore.



Sébastien.



One of the casualties in the war on spam is mail forwarders.

The built-in postfix way to control the sender/recipient pairs is
restriction classes. This works well for a small number of
combinations, but quickly gets unmanageable.
http://www.postfix.org/RESTRICTION_CLASS_README.html

You can use a postfix policy service such as postfwd to create a
list of allowed senders for some particular recipient.  This isn't
difficult, but will require manual intervention anytime a change is
needed.  Postfwd may be kinda old, but is still widely used.
http://postfwd.org/

Another alternative is to use one of the existing perl (or java)
milters such as milter-regex and add your sender/recipient checks
there.  Some ideas here, but just about any milter should work:
http://www.postfix.org/addon.html

Or just blow the whole thing up.  Either host the mail locally and
stop forwarding, or migrate your domain to gsuite so it's all inside
their system.



 -- Noel Jones

Re: disable receiving for particular email

[Poliman - Serwis]

Do you have maybe other better options? I am open for all nice suggestions.
:)

2017-10-20 14:43 GMT+02:00 /dev/rob0 :

> On Fri, Oct 20, 2017 at 11:12:17AM +0200,
>Matus UHLAR - fantomas wrote:
> > On 20.10.17 08:00, Poliman - Serwis wrote:
> > > Hi all. I would like to create "do not reply" email account. The
> > > simpliest way is create an email account and disable receiving.
>
> As was suggested upthread, the simplest way is NOT to create the
> account.
>
> > > Which option in Postfix permit disable receiving for particular
> > > email?
> >
> > you can disable receiving mail for such account using
> > check_recipient_access
>
> Some references of interest:
> http://www.postfix.org/SMTPD_ACCESS_README.html
> http://www.postfix.org/postconf.5.html#check_recipient_access
> http://www.postfix.org/access.5.html
>
> > note that:
> > 1. anyone doing address verification will block the address
> > 2. systems that block senders who mail nonexistent addresses will block
> you
> >you won't find out you mail nonexistent addresses after mail leaves
> your
> >server, since you reject bounces to that addresses
> > 3. anyone getting angry for sending mail from nonexistent address will
> >block the address manually
> > 4. anyone getting angry for sending mail from nonexistent address may
> block
> >you manually.
> >
> > I recommend using real, existent address and check its content once
> > upon a time. You don't want to get blocked (see points 2. and 4.)
>
> Absolutely.  This is better than the DISCARD suggestion.  I find that
> people who ask for "do not reply" addresses usually don't understand
> what they are asking for, nor what they will get when they have it.
> --
>   http://rob0.nodns4.us/
>   Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
>



-- 

*Pozdrawiam / Best Regards*
*Piotr Bracha*

Block IP rcpt-to or block MX

[Emanuel]

Hello,

Is it possible to create a list where the IP of certain recipients can 
be blocked?


Here and example:

Oct 19 10:15:09 smtp01 postfix/smtpd[11048]: 5C28C20018459: 
client=myserver[172.17.111.242]
Oct 19 10:15:09 smtp01 postfix/cleanup[6836]: 5C28C20018459: 
message-id=<59e8a0ca77...@domain.com>
Oct 19 10:15:09 smtp01 postfix/qmgr[3054]: 5C28C20018459: 
from=, size=16981, nrcpt=1 (queue active)
Oct 19 10:15:25 smtp01 smht-101-41/smtp[7698]: 5C28C20018459: 
to=, relay=mail.h-email.net[198.133.159.122]:25, 
delay=16, delays=0.15/0/9.2/6.3, dsn=2.0.0, status=sent (250 Queued!)

Oct 19 10:15:25 smtp01 postfix/qmgr[3054]: 5C28C20018459: removed

Our users incorrectly type the domain name of the recipient.

*hotmial.com ==> hotmail.com*

My idea is block the MX or IP ==> mail.h-email.net - 198.133.159.122

Any ideas?

Regards,

Emanuel.

--
envialosimple.com   
Emanuel Gonzalez
Deliverability Specialist
emanuel.gonza...@donweb.com 
www.envialosimple.com 
by donweb 

Nota de confidencialidad: Este mensaje y archivos adjuntos al mismo son 
confidenciales, de uso exclusivo para el destinatario del mismo. La 
divulgación y/o uso del mismo sin autorización por parte de DonWeb.com 
queda prohibida.
DonWeb.com no se hace responsable del mensaje por la falsificación y/o 
alteración del mismo.
De no ser Ud el destinatario del mismo y lo ha recibido por error, por 
favor, notifique al remitente y elimínelo de su sistema.
Confidentiality Note: This message and any attachments (the message) are 
confidential and intended solely for the addressees. Any unauthorised 
use or dissemination is prohibited by DonWeb.com.

DonWeb.com shall not be liable  for the message if altered or falsified.
If you are not the intended addressee of this message, please cancel it 
immediately and inform the sender
Nota de Confidencialidade: Esta mensagem e seus eventuais anexos podem 
conter dados confidenciais ou privilegiados.
Se você os recebeu por engano ou não é um dos destinatários aos quais 
ela foi endereçada, por favor destrua-a e a todos os seus eventuais 
anexos ou copias realizadas, imediatamente.
É proibida a retenção, distribuição, divulgação ou utilização de 
quaisquer informações aqui contidas.
Por favor, informenos sobre o recebimento indevido desta mensagem, 
retornando-a para o autor.

Re: disable receiving for particular email

[/dev/rob0]

On Fri, Oct 20, 2017 at 11:12:17AM +0200,
   Matus UHLAR - fantomas wrote:
> On 20.10.17 08:00, Poliman - Serwis wrote:
> > Hi all. I would like to create "do not reply" email account. The 
> > simpliest way is create an email account and disable receiving.

As was suggested upthread, the simplest way is NOT to create the 
account.

> > Which option in Postfix permit disable receiving for particular 
> > email?
> 
> you can disable receiving mail for such account using
> check_recipient_access

Some references of interest:
http://www.postfix.org/SMTPD_ACCESS_README.html
http://www.postfix.org/postconf.5.html#check_recipient_access
http://www.postfix.org/access.5.html

> note that:
> 1. anyone doing address verification will block the address
> 2. systems that block senders who mail nonexistent addresses will block you
>you won't find out you mail nonexistent addresses after mail leaves your
>server, since you reject bounces to that addresses
> 3. anyone getting angry for sending mail from nonexistent address will
>block the address manually
> 4. anyone getting angry for sending mail from nonexistent address may block
>you manually.
> 
> I recommend using real, existent address and check its content once
> upon a time. You don't want to get blocked (see points 2. and 4.)

Absolutely.  This is better than the DISCARD suggestion.  I find that 
people who ask for "do not reply" addresses usually don't understand 
what they are asking for, nor what they will get when they have it.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: bcc emails to two addresses

[Tavolodo Bela]

>
> On 19.10.17 17:01, A. Schulze wrote:
>
>> it's simpler.
>> you do not need a separate transport to enforce
>> destination_recipient_limit=1
>>
>> pcrefile:
>>  /(.+)@(.+)/ someuser+${1}_at_${2}@archive
>>  /(.*)/  someuser+${1}@archive
>>
>> main.cf:
>>  recipient_bcc_maps = pcre:/path/to/pcrefile
>>
>
>
Thank you Andreas, I'll check your solution.

Bela

Re: disable receiving for particular email

[Matus UHLAR - fantomas]

On 20.10.17 08:00, Poliman - Serwis wrote:

Hi all. I would like to create "do not reply" email account. The simpliest
way is create an email account and disable receiving. Which option in
Postfix permit disable receiving for particular email?


you can disable receiving mail for such account using
check_recipient_access

note that:
1. anyone doing address verification will block the address
2. systems that block senders who mail nonexistent addresses will block you
   you won't find out you mail nonexistent addresses after mail leaves your
   server, since you reject bounces to that addresses
3. anyone getting angry for sending mail from nonexistent address will
   block the address manually
4. anyone getting angry for sending mail from nonexistent address may block
   you manually.

I recommend using real, existent address and check its content once upon a
time. You don't want to get blocked (see points 2. and 4.)
--
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.
Spam is for losers who can't get business any other way.

Re: disable receiving for particular email

[Ralph Seichter]

On 20.10.2017 08:00, Poliman - Serwis wrote:

> I would like to create "do not reply" email account.

If by that you mean throwing away incoming email silently instead of
generating rejection errors, a polite way to do it is using recipient
restrictions.

  smtpd_recipient_restrictions = ... check_recipient_access 
pcre:/etc/postfix/recipient_access ...

  # pcre:/etc/postfix/recipient_access
  /^(?:devnull|noreply)\@domain\.tld$/ DISCARD

Make sure you accept incoming mail for these special addresses, and the
DISCARD action will take care of the rest.

-Ralph

Re: bcc emails to two addresses

[Matus UHLAR - fantomas]

A. Schulze:


(braindump, I'll post an update tomorrow if I'm wrong...)

pcrefile:
 /^(.+)\@(.+)$/ someuser+$1_at_$2@archive

transport_maps:
 archivesmtp_to_archive:

main.cf:
recipient_bcc_maps = pcre:/path/to/pcrefile
transport_maps = hash:/path/to/transport_maps
smtp_to_archive_destination_recipient_limit = 1

master.cf
 smtp_to_archiveunix  - - - - - smtp
  -o syslog_name=postfix/to_archive


On 19.10.17 17:01, A. Schulze wrote:

it's simpler.
you do not need a separate transport to enforce destination_recipient_limit=1

pcrefile:
 /(.+)@(.+)/ someuser+${1}_at_${2}@archive
 /(.*)/  someuser+${1}@archive

main.cf:
 recipient_bcc_maps = pcre:/path/to/pcrefile


does it need pcre at all?
I thought simply having different destination domains in recipient_bcc_maps
(hash: style map) should be enough...

--
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.
Support bacteria - they're the only culture some people have. 

Re: disable receiving for particular email

[titanus]

Fri, 20 Oct 2017 08:00:35 +0200 skrev Poliman - Serwis :

> Hi all. I would like to create "do not reply" email account. The simpliest
> way is create an email account and disable receiving. Which option in
> Postfix permit disable receiving for particular email?
> 

Why not use a non-existent address that Postfix reject?

Personally I would think it's bad service for the recivers, but YMMW.

Best

disable receiving for particular email

[Poliman - Serwis]

Hi all. I would like to create "do not reply" email account. The simpliest
way is create an email account and disable receiving. Which option in
Postfix permit disable receiving for particular email?

-- 

*Pozdrawiam / Best Regards*
*Piotr Bracha*