rejecting 'nested' from address ?

2018-11-16 Thread Voytek
a user started getting many spam/malware with like 'nested' from:

<"mick@cinkmedia.comgeranc"@gmail.com>

<"m...@cinkmedia.com.abc"@expertsmeetings.org>

I'm waiting for a full header from him, can anything be done in Postfix ?
or where ? to reject/block ?

V





Re: rejecting 'nested' from address ?

2018-11-16 Thread Wietse Venema
Voytek:
> a user started getting many spam/malware with like 'nested' from:
> 
> <"mick@cinkmedia.comgeranc"@gmail.com>
> 
> <"m...@cinkmedia.com.abc"@expertsmeetings.org>
> 
> I'm waiting for a full header from him, can anything be done in Postfix ?
> or where ? to reject/block ?

/etc/postfix/sender_pcre:
   /@.*@/   reject

/etc/postfix/main.cf:
   smtpd_sender_restrictions = 
check_sender_access pcre:/etc/postfix/sender_pcre

Don't use this in header_checks.

Wietse


avoid external emails that the from=< and the to=< are the same user

2018-11-16 Thread Francesc Peñalvez
Lately we are receiving spam mails that apparently the mail from the and 
the to is the same. How is it possible to avoid this?. I have configured 
postfix to avoid the relay of emails and to be able to send mail through 
my postfix is necessary the auth , these emails are sent externally from 
several ips and seeing the logs of those emails are not authenticated


*
Este mensaje y todos los archivos adjuntos son confidenciales y de uso 
exclusivo por parte
de su/sus destinatario/s. Si usted ha recibido este mensaje por error, le 
agradecemos que
lo notifique inmediatamente al remitente y destruya el mensaje. Queda prohibida 
cualquier
modificación, edición, uso o divulgación no autorizados. El Emisor no se hace 
responsable
de este mensaje si ha sido modificado, distorsionado, falsificado, infectado 
por un virus o
editado o difundido sin autorización.


***
This message and any attachments are confidential and intended for the named 
addressee(s) only.
If you have received this message in error, please notify immediately the 
sender, then delete
the message. Any unauthorized modification, edition, use or dissemination is 
prohibited.
The sender shall not be liable for this message if it has been modified, 
altered, falsified, infected
by a virus or even edited or disseminated without authorization.
***




smime.p7s
Description: Firma criptográfica S/MIME


Re: rejecting 'nested' from address ?

2018-11-16 Thread Voytek
On Sat, November 17, 2018 12:01 am, Wietse Venema wrote:


thanks !

>> or where ? to reject/block ?
>
> /etc/postfix/sender_pcre:
> /@.*@/   reject
>
>
> /etc/postfix/main.cf:
> smtpd_sender_restrictions = check_sender_access
> pcre:/etc/postfix/sender_pcre

I currently have as so, add as 1st or last ?

...
smtpd_sender_restrictions =
 permit_mynetworks,
 permit_sasl_authenticated
...


> Don't use this in header_checks.





Re: avoid external emails that the from=< and the to=< are the same user

2018-11-16 Thread Dominic Raferd
On Fri, 16 Nov 2018 at 13:20, Francesc Peñalvez  wrote:
>
> Lately we are receiving spam mails that apparently the mail from the and
> the to is the same. How is it possible to avoid this?. I have configured
> postfix to avoid the relay of emails and to be able to send mail through
> my postfix is necessary the auth , these emails are sent externally from
> several ips and seeing the logs of those emails are not authenticated

SpamAssassin 3.4.2 has the FromNameSpoof Plugin which should help.

You can also write your own header_checks test like this (which is
broader than your use case):
if /^From:/
#   emails from our domains and some others are not subject to restrictions here
/((mydomain1\.tld|mydomain2\.tld)>?\s*$/ DUNNO
#   but try to block emails that pretend to be from us
# (a) e.g. From: domi...@mydomain1.tld 
/^(.*mydomain1\.tld"? <.*)$/ REJECT From header impersonation type 1
# (b) e.g. From: Dominic Raferd 
if /^From: ?(Mr?s? )?(D(ominic)?.*Raferd)/
#  but allow some exceptions... e.g. apple, launchpad
!/(@bugs\.launchpad\.net|noreply@email\.apple\.com)>?\s*$/ REJECT From
header impersonation type 2
endif


Re: rejecting 'nested' from address ?

2018-11-16 Thread Wietse Venema
Voytek:
> On Sat, November 17, 2018 12:01 am, Wietse Venema wrote:
> 
> 
> thanks !
> 
> >> or where ? to reject/block ?
> >
> > /etc/postfix/sender_pcre:
> > /@.*@/   reject
> >
> >
> > /etc/postfix/main.cf:
> > smtpd_sender_restrictions = check_sender_access
> > pcre:/etc/postfix/sender_pcre
> 
> I currently have as so, add as 1st or last ?
> 
> ...
> smtpd_sender_restrictions =
>  permit_mynetworks,
>  permit_sasl_authenticated
> ...

If first, then it will affect local, authorized, and remote clients.

If last, then it will affect remote clients.

Wietse


Re: avoid external emails that the from=< and the to=< are the same user

2018-11-16 Thread Wietse Venema
Francesc Pe?alvez:
> Lately we are receiving spam mails that apparently the mail from the and 
> the to is the same. How is it possible to avoid this?. I have configured 
> postfix to avoid the relay of emails and to be able to send mail through 
> my postfix is necessary the auth , these emails are sent externally from 
> several ips and seeing the logs of those emails are not authenticated

Postfix 3.0 and later:

/etc/postfix/main.cf:
smtpd_sender_restrictions = 
permit_mynetworks
permit_sasl_authenticated
check_sender_access inline:{
{ example.com = REJECT local sender from unauthorized client }
{ other.example = REJECT local sender from unauthorized client }
}

Instead of example.com and other.example, specify your email domains.

Note: this breaks email from remote mail forwarders or from remote
distribution lists that don't reset the sender address.

Wietse


RE: looking for any options to better deal with mail looping

2018-11-16 Thread Fazzina, Angelo
Hi again,
Even though my configuration does what I need it to do, it seems to have broken 
something else that needs to still work.
Did I forget something or just did this wrong ?
Will this setting allow whitelisting something to help the issue 
"smtpd_sender_restrictions"
I maybe just confusing the processing Postfix does AFA  envelope TO and FROM 
and header TO and FROM...?

Here is the test showing what is broken:

[root@mta5 ~]# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mta5.uits.uconn.edu ESMTP Postfix (2.10.1)
ehlo listserv.uconn.edu
250-mta5.uits.uconn.edu
250-PIPELINING
250-SIZE 31457280
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
mail from:dailydig...@listserv.uconn.edu
250 2.1.0 Ok
rcpt to:uconn_employee...@listserv.uconn.edu
450 4.1.1 : Recipient address rejected: 
unverified address: Address verification in progress
quit
221 2.0.0 Bye
Connection closed by foreign host.

Here is my current config in main.cf :
smtpd_recipient_restrictions = reject_unknown_recipient_domain, 
reject_unverified_recipient, permit_mynetworks, permit_sasl_authenticated, 
reject_unauth_destination
relay_recipient_maps = hash:/etc/postfix/files/sender_relay_domains,  
mysql:/etc/postfix/files/mysql_pn.cf
[root@mta5 files]# more sender_relay_domains
@listserv.uconn.edu  OK

Here is [most of] the headers of a real email that gets delivered to my 
first.l...@uconn.edu address even though it does not appear anywhere in the 
headers :

Received: from SN4PR0501MB3808.namprd05.prod.outlook.com
 (2603:10b6:406:a8::38) by BN7PR05MB5859.namprd05.prod.outlook.com with HTTPS
 via BN7PR11CA0025.NAMPRD11.PROD.OUTLOOK.COM; Fri, 16 Nov 2018 16:00:54 +
Received: from SN4PR0501CA0078.namprd05.prod.outlook.com
 (2603:10b6:803:22::16) by SN4PR0501MB3808.namprd05.prod.outlook.com
 (2603:10b6:803:49::22) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.11; Fri, 16 Nov
 2018 16:00:52 +
Received: from SN1NAM01FT027.eop-nam01.prod.protection.outlook.com
 (2a01:111:f400:7e40::206) by SN4PR0501CA0078.outlook.office365.com
 (2603:10b6:803:22::16) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.14 via Frontend
 Transport; Fri, 16 Nov 2018 16:00:51 +
Authentication-Results: spf=none (sender IP is 137.99.25.243)
 smtp.mailfrom=LISTSERV.UCONN.EDU; uconn.mail.onmicrosoft.com; dkim=pass
 (signature was verified)
 header.d=mta4.uits.uconn.edu;uconn.mail.onmicrosoft.com; dmarc=bestguesspass
 action=none header.from=LISTSERV.UCONN.EDU;
Received-SPF: None (protection.outlook.com: LISTSERV.UCONN.EDU does not
 designate permitted sender hosts)
Received: from mta4.uits.uconn.edu (137.99.25.243) by
 SN1NAM01FT027.mail.protection.outlook.com (10.152.65.58) with Microsoft SMTP
 Server id 15.20.1339.10 via Frontend Transport; Fri, 16 Nov 2018 16:00:49
 +
Received: from MSB-P-Listserv (MSB-P-Listserv.grove.ad.uconn.edu [137.99.30.25])
by mta4.uits.uconn.edu (Postfix) with ESMTP id 2A8B0180AC15;
Fri, 16 Nov 2018 11:00:47 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 mta4.uits.uconn.edu 2A8B0180AC15
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mta4.uits.uconn.edu;
s=dkim1; t=1542384047;
bh=23m3HvmPkkiL8AhD31WJX+Es7CXHECqjFcBk/2u1CNA=;
h=Date:Reply-To:From:Subject:To:List-Help:List-Unsubscribe:
 List-Subscribe:List-Owner:List-Archive:From;
b=vqj2Xt564wl9mezVZt3B/Im27ZlxA1mAZD7NtBbxQXvOoQRhpFhhqHdCgKvLZ/Czv
 mC1ETdTEpntS9dsNmt16ZXQcB0bk76C2TBz0Uso7sMiXtus5Gx/dn107ZIl1VF7mRM
 krEhqkeI0hu9LAAbEbxvxFGOyyONuDqg+QdpeJa8=
Received: by LISTSERV.UCONN.EDU (LISTSERV-TCP/IP release 16.0) with spool id
  18870947 for uconn_employee...@listserv.uconn.edu; Fri, 16 Nov 2018
  11:00:07 -0500
MIME-Version: 1.0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
Message-ID: 
Date: Fri, 16 Nov 2018 11:00:07 -0500
Reply-To: do-not-re...@listserv.uconn.edu
Sender: All UConn Employees and Graduate Students

From: UConn Daily Digest 
Subject: [UCONN_EMPLOYEES-L] Faculty/Staff Daily Digest
To: uconn_employee...@listserv.uconn.edu
Precedence: list
List-Help: ,
   
List-Unsubscribe:
 
List-Subscribe: 
List-Owner: 
List-Archive: 
Return-Path: owner-uconn_employee...@listserv.uconn.edu
X-MS-Exchange-Organization-ExpirationStartTime: 16 Nov 2018 16:00:51.8366
 (UTC)
X-MS-Exchange-Organization-ExpirationStartTimeReason: OriginalSubmit
X-MS-Exchange-Organization-Expira

Re: looking for any options to better deal with mail looping

2018-11-16 Thread Noel Jones
On 11/16/2018 2:41 PM, Fazzina, Angelo wrote:
> Hi again,
> Even though my configuration does what I need it to do, it seems to have 
> broken something else that needs to still work.
> Did I forget something or just did this wrong ?
> Will this setting allow whitelisting something to help the issue 
> "smtpd_sender_restrictions"
> I maybe just confusing the processing Postfix does AFA  envelope TO and FROM 
> and header TO and FROM...?

The To: From: headers have no relation to postfix delivery. All
delivery is based on envelope addresses.


> 
> Here is the test showing what is broken:
>... 
> 250 2.1.0 Ok
> rcpt to:uconn_employee...@listserv.uconn.edu
> 450 4.1.1 : Recipient address rejected: 
> unverified address: Address verification in progress
>...

Nothing wrong here.  The address verification is in progress and the
client is free to retry delivery.  Presumably the verification
completed a few seconds later.  This will be noted in the log.

If you wish to exempt some recipient from verification, add a
check_recipient_access map before the reject_unverified_recipient


> Here is my current config in main.cf :
> smtpd_recipient_restrictions = reject_unknown_recipient_domain, 
> reject_unverified_recipient, permit_mynetworks, permit_sasl_authenticated, 
> reject_unauth_destination

Typically, reject_unverified_recipient would be after
reject_unauth_destination to prevent verifying random internet
recipients, or in a check_recipient_access map to limit the scope of
the checks.  Something like:

dontverif...@example.com  DUNNO
listserv.example.com  DUNNO
example.com  reject_unverified_recipient


> relay_recipient_maps = hash:/etc/postfix/files/sender_relay_domains,  
> mysql:/etc/postfix/files/mysql_pn.cf
>   [root@mta5 files]# more sender_relay_domains
>   @listserv.uconn.edu  OK

relay_recipient_maps does not exempt addresses from the
reject_unverified_recipient check.  See the above example for how to
exempt addresses from verification.


> 
> Here is [most of] the headers of a real email that gets delivered to my 
> first.l...@uconn.edu address even though it does not appear anywhere in the 
> headers :

Headers are irrelevant for this discussion.  Postfix logs will show
what is happening.




  -- Noel Jones