Re: Port 587 users question

[lists]

I should have mentioned the mail system is on a VPS and I'm the only user. And 
yes, trouble makers are on the Internet. 

What lead me to this was I did bzgrep "max auth" and noticed both smtp and 
submission was found. (max auth as in checking anvil rate limiting). Since I'm 
the only person that should (we hope) have valid usernames and passwords, 
blocking the port from the internet trouble makers make sense  ‎if there is no 
legitimate reason for others to use the port. 

My blocking list of trouble makers is self generated, so I won't be on it.

I do think servers hammering 587 is odd, but I noticed I get about two a day. 
And these are just when rate limiting come in. I suppose they could be 
misconfigured servers.

  Original Message  
From: b...@bitrate.net
Sent: Sunday, November 27, 2016 5:15 PM
To: Postfix users
Subject: Re: Port 587 users question

On Nov 27, 2016, at 16.15, li...@lazygranch.com wrote:
> 
> I hate to bug the list for what is probably a dumb question, but is there any 
> situation where an unauthorized user needs to connect to port 587? I'm 
> wondering if there is some oddball "edge" case.

well, i suppose it would depend upon what your definition of "unauthorized" 
actually is, but making some assumptions, the short answer is likely no. since 
you refer below to blocking troublemakers, presumably we're talking about the 
internet, rather than an internal or such network where there might be the 
occasional device which cannot perform smtp auth, encryption, etc., and for 
which an exception might be necessary [for those edge cases, i use 
check_client_access and a cidr map].

> My thought is to use my ipfw table of known trouble makers to block 587.

honestly, i'm not sure i'd bother. it may be fine, but it's also one more thing 
to include risk for a false positive.

Re: Port 587 users question

[btb]

On Nov 27, 2016, at 16.15, li...@lazygranch.com wrote:
> 
> I hate to bug the list for what is probably a dumb question, but is there any 
> situation where an unauthorized user needs to connect to port 587? I'm 
> wondering if there is some oddball  "edge" case.

well, i suppose it would depend upon what your definition of "unauthorized" 
actually is, but making some assumptions, the short answer is likely no.  since 
you refer below to blocking troublemakers, presumably we're talking about the 
internet, rather than an internal or such network where there might be the 
occasional device which cannot perform smtp auth, encryption, etc., and for 
which an exception might be necessary [for those edge cases, i use 
check_client_access and a cidr map].

> My thought is to use my ipfw table of known trouble makers to block 587.

honestly, i'm not sure i'd bother.  it may be fine, but it's also one more 
thing to include risk for a false positive.

Re: Milters and notification on DISCARD

[Stavros Tsolakos]

Hi.

> Including spamming innocent people with notifications for email
> that they did not send.

You are right, but in my case it is about blocking sending to people
outside a local 'ecosystem'. So spamming is quite unlikely since there
are no relay servers configured either.

Anyway, thank you for your help.

Stavros

Re: Milters and notification on DISCARD

[Wietse Venema]

Stavros Tsolakos:
> > What is the nature of the client? If it is an MTA, then it must
> > return a message to sender; if it is an MUA, then don't count on
> > such clients to put a non-delivery notice in the sender's inbox.
> 
> Yes, it is a MUA. Several MUAs actually: a Rainloop webmail client, a
> CLAWS mail client etc. All report that they failed to queue the message,
> which is exactly what I wanted to happen. Is there a trigger for postfix
> to send a custom failure notice email to the sender when this happens?

No. I suppose there is no trigger for MUA clients to leave unsent
email in the user's inbox, or to report the server's response.

There is a one-bit 'can bounce' flag in the Postfix cleanup server
to create an NDR for email that is picked up from the Postfix
sendmail command, but I don't think that it is a good idea to set
that flag for email received via SMTP. Better get the clients fixed
to report the server response to the user.

> Alternatively, I could do it myself from the milter's code i.e. call the
> sendmail program to do the job. Actually, this can make things as
> flexible as needed.

Including spamming innocent people with notifications for email
that they did not send.

Wietse

Port 587 users question

[lists]

I hate to bug the list for what is probably a dumb question, but is there any 
situation where an unauthorized user needs to connect to port 587? I'm 
wondering if there is some oddball  "edge" case. 

My thought is to use my ipfw table of known trouble makers to block 587. 
‎

Re: Milters and notification on DISCARD

[Stavros Tsolakos]

Hi.

> What is the nature of the client? If it is an MTA, then it must
> return a message to sender; if it is an MUA, then don't count on
> such clients to put a non-delivery notice in the sender's inbox.
> 

Yes, it is a MUA. Several MUAs actually: a Rainloop webmail client, a
CLAWS mail client etc. All report that they failed to queue the message,
which is exactly what I wanted to happen. Is there a trigger for postfix
to send a custom failure notice email to the sender when this happens?
Alternatively, I could do it myself from the milter's code i.e. call the
sendmail program to do the job. Actually, this can make things as
flexible as needed.

Thank you,

Stavros

Re: Milters and notification on DISCARD

[Wietse Venema]

Stavros Tsolakos:
> milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 4.5.1 Rejected
> because I said so;

What is are Milter call and arguments that send the response?

> "Rejected because I said so" is a test reason I have written. Still, the
> client reports a failure but no failure message appears in the sender's
> inbox.

What is the nature of the client? If it is an MTA, then it must
return a message to sender; if it is an MUA, then don't count on
such clients to put a non-delivery notice in the sender's inbox.

Wietse

Re: Milters and notification on DISCARD

[Stavros Tsolakos]

Hi.

>> I have tried REJECTing it, however sending just failed without further
>> explanation for the user, although the reason appeared fine in the log
>> file. To avoid client specific issues, I would need something similar to
>> the undeliverable mail notifications emails sent to the sender's mailbox.
> 
> At which SMTP protocol stage are you issuing the REJECT response?
> Try rejecting at end-of-data.

This is what I am doing (return a REJECT at the end of the body).

I am getting this line in the log file:

milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 4.5.1 Rejected
because I said so;

"Rejected because I said so" is a test reason I have written. Still, the
client reports a failure but no failure message appears in the sender's
inbox.

Of course I am doing something wrong due to my rookieness, but how may I
troubleshoot it?

Thanks,

Stavros

Re: Milters and notification on DISCARD

[Wietse Venema]

Stavros Tsolakos:
> Hi list.
> 
> I am really new to postfix and email-under-the-hood in general.
> 
> I have written a milter which in some cases DISCARDs the message, so
> that it may not be sent at all. Is there a way of making postfix notify
> the sender that their email was discarded?

Yes, it is called REJECT.

> I have tried REJECTing it, however sending just failed without further
> explanation for the user, although the reason appeared fine in the log
> file. To avoid client specific issues, I would need something similar to
> the undeliverable mail notifications emails sent to the sender's mailbox.

At which SMTP protocol stage are you issuing the REJECT response?
Try rejecting at end-of-data.

Wietse

Re: Procmail Advice

[Wietse Venema]

@lbutlr:
> On Nov 26, 2016, at 11:30 AM, E. Recio  wrote:
> > On 11/22/2016 10:47 AM, @lbutlr wrote:
> >>=20
> >> reject_unknown_reverse_client_hostname,
> >>=20
> >> but I also use:
> >> reject_non_fqdn_recipient,
> >> reject_unknown_sender_domain,
> >> reject_invalid_hostname,
> 
> > Wow, these settings cut down on spam by a lot! My concern is that if =
> someone is on a private remote NAT network (sending real) example.com =
> (sending real) 1.2.3.4 but the host behind the 1.2.3.4 NAT is (sending =
> host) example.local (sending host) 10.1.2.3 and sends email by directly =
> connecting to my postfix server via 25, would the email get to me?
> 
> No. A host hiding behind a NAT should never be connecting directly to =
> you, that's rather the point.

They can, but they should announce an SMTP hostname that matches
the external IP address.  In the Postfix case, that is controlled
with the smtp_helo_name parameter. If Postfix needs to deliver mail
to internal and external systems, use separate SMTP clients for
internal and external mail, and set smtp_helo_name on the outbound
SMTP client (in master.cf).

Wietse

Milters and notification on DISCARD

[Stavros Tsolakos]

Hi list.

I am really new to postfix and email-under-the-hood in general.

I have written a milter which in some cases DISCARDs the message, so
that it may not be sent at all. Is there a way of making postfix notify
the sender that their email was discarded?

I have tried REJECTing it, however sending just failed without further
explanation for the user, although the reason appeared fine in the log
file. To avoid client specific issues, I would need something similar to
the undeliverable mail notifications emails sent to the sender's mailbox.

Thank you very much!

Stavros

PS: I am using Postfix 2.6.6 on an old CentOS 6.8 x64

Re: Procmail Advice

[@lbutlr]

On Nov 26, 2016, at 11:30 AM, E. Recio  wrote:
> On 11/22/2016 10:47 AM, @lbutlr wrote:
>> 
>> reject_unknown_reverse_client_hostname,
>> 
>> but I also use:
>> reject_non_fqdn_recipient,
>> reject_unknown_sender_domain,
>> reject_invalid_hostname,

> Wow, these settings cut down on spam by a lot! My concern is that if someone 
> is on a private remote NAT network (sending real) example.com (sending real) 
> 1.2.3.4 but the host behind the 1.2.3.4 NAT is (sending host) example.local 
> (sending host) 10.1.2.3 and sends email by directly connecting to my postfix 
> server via 25, would the email get to me?

No. A host hiding behind a NAT should never be connecting directly to you, 
that’s rather the point.

Re: AW: Possible Bug ? postfix 3.1.0-3 fails on mysql table lookup

[John Fawcett]

On 11/27/2016 01:47 PM, John Fawcett wrote:
> On 11/23/2016 10:54 PM, j...@conductive.de wrote:
>> On 2016-11-23 21:57, John Fawcett wrote:
>>> On 11/22/2016 01:35 AM, Joel Linn wrote:
 Hey Guys,

 this issue has decayed a bit but I now finally found the time (and the
 nerves) to integrate the fix in my system.
 I'm running Ubuntu 16.04 and trying not change to many things and be
 able to have clean comparison I applied the patch to the apt sources
 and only replaced the postfix-mysql package (ubuntu is using 3.1.0 it
 seems) with my own.
 I introduced some stored procedures and from my tests I conclude it
 works. I will see in the next couple of days if there are issues I
 overlooked.
 I ran into an issue where I was returning no result set using
 "smtpd_recipient_restrictions = check_recipient_access mysql:/[...]".
 I'm not sure if that's an dict_mysql issue or caused by design
 upstream. I overcame that by doing "select 1 from dual where false"
 when I don't have anything else to return, which basically is an empty
 result set.

 Thanks very much for your work,
 Joel
>>> Joel
>>>
>>> can you provide some more information to reproduce the issue you
>>> mentioned?
>>>
>>> John
>> Sure I can. Have a look at my log:
>>
>> Nov 23 22:42:49 leuchtkanone postfix/smtpd[5863]: connect from
>> divmail1.helmholtz-berlin.de[134.30.104.21]
>> Nov 23 22:42:49 leuchtkanone postfix/smtpd[5863]: warning:
>> mysql:/etc/postfix/sql/recipient-access.cf: table lookup problem
>> Nov 23 22:42:49 leuchtkanone postfix/smtpd[5863]: NOQUEUE: reject:
>> RCPT from divmail1.helmholtz-berlin.de[134.30.104.21]: 451 4.3.5
>> : Recipient address rejected: Server configuration
>> error; from= to=
>> proto=ESMTP helo=
>>
>> I used this empty test procedure (query = CALL ret_empty;):
>>
>> CREATE DEFINER=`vmail`@`localhost` PROCEDURE `ret_empty`()
>> BEGIN
>> END
>>
>> In my procedure I had some code paths return a result and some not.
>> Like I said i'm now using "SELECT 1 FROM dual WHERE false;" for those
>> dead paths, this simulates the behavior of the previous solution (one
>> line query) which always returns a result set, even if it's empty.
> Joel
>
> with MySQL procedures every SELECT statement that is executed produces a
> result set. In my patch I explicitly check to make sure there are no
> multiple result sets, but I do not check for no result. That could be
> improved upon, to give a specific warning that no result sets were
> returned. However, that will always be a lookup failure. The stored
> procedure (based on the way the patch is written) must always return a
> result set even if that result set is empty.
>
> Your solution with returning an empty result set when there is no other
> result (SELECT 1 FROM DUAL WHERE FALSE) looks correct.
>
> John
>
Revised patch to improve error reporting when no result set containing
data is returned

diff -ur postfix-3.2-20161106-orig/proto/mysql_table
postfix-3.2-20161106/proto/mysql_table
--- postfix-3.2-20161106-orig/proto/mysql_table 2016-10-01
15:44:52.0 +0200
+++ postfix-3.2-20161106/proto/mysql_table  2016-11-27
10:08:05.535236131 +0100
@@ -289,6 +289,39 @@
 #  certificate.
 # .sp
 #  This parameter is available with Postfix 2.11 and later.
+# USING MYSQL STORED PROCEDURES
+# .ad
+# .fi
+#  With Postfix 3.2 it is possible to call a stored procedure
+#  instead of using a SELECT statement in the query, e.g.
+#
+# .nf
+#  query = CALL lookup('%s')
+# .fi
+#
+#  The preivously described '%' expansions can be used in the
+#  parameter(s) to the stored procedure.
+#
+#  The stored procedure must return data with a single result
+#  set. Multiple result sets are not supported and will
+#  produce a warning and no valid result. Stored procedures in
+#  mysql produce an additional result set without data which
+#  indicates the final status of the stored procedure. If this
+#  final status is an error then any previous returned data
+#  will not be used.
+#
+#  The following is an example of a stored procedure returning
+#  data with a single result set:
+#
+# .nf
+#  CREATE [DEFINER=`user`@`host`] PROCEDURE
+#  `lookup`(IN `param` VARCHAR(255))
+#  READS SQL DATA
+#  SQL SECURITY INVOKER
+#  BEGIN
+#  select goto from alias where address=param;
+#  END
+# .fi
 # OBSOLETE QUERY INTERFACE
 # .ad
 # .fi
diff -ur postfix-3.2-20161106-orig/src/global/dict_mysql.c
postfix-3.2-20161106/src/global/dict_mysql.c
--- postfix-3.2-20161106-orig/src/global/dict_mysql.c   2016-09-25
17:27:11.0 +0200
+++ postfix-3.2-20161106/src/global/dict_mysql.c2016-11-27
13:56:50.956334035 +0100
@@ -187,6 +187,7 @@
 #include 
 #include 
 #include 
+#include 

 #ifdef STRCASECMP_IN_STRINGS_H
 #include 
@@ -519,6 +520,10 @@
 

Re: AW: Possible Bug ? postfix 3.1.0-3 fails on mysql table lookup

[John Fawcett]

On 11/23/2016 10:54 PM, j...@conductive.de wrote:
> On 2016-11-23 21:57, John Fawcett wrote:
>> On 11/22/2016 01:35 AM, Joel Linn wrote:
>>> Hey Guys,
>>>
>>> this issue has decayed a bit but I now finally found the time (and the
>>> nerves) to integrate the fix in my system.
>>> I'm running Ubuntu 16.04 and trying not change to many things and be
>>> able to have clean comparison I applied the patch to the apt sources
>>> and only replaced the postfix-mysql package (ubuntu is using 3.1.0 it
>>> seems) with my own.
>>> I introduced some stored procedures and from my tests I conclude it
>>> works. I will see in the next couple of days if there are issues I
>>> overlooked.
>>> I ran into an issue where I was returning no result set using
>>> "smtpd_recipient_restrictions = check_recipient_access mysql:/[...]".
>>> I'm not sure if that's an dict_mysql issue or caused by design
>>> upstream. I overcame that by doing "select 1 from dual where false"
>>> when I don't have anything else to return, which basically is an empty
>>> result set.
>>>
>>> Thanks very much for your work,
>>> Joel
>> Joel
>>
>> can you provide some more information to reproduce the issue you
>> mentioned?
>>
>> John
> Sure I can. Have a look at my log:
>
> Nov 23 22:42:49 leuchtkanone postfix/smtpd[5863]: connect from
> divmail1.helmholtz-berlin.de[134.30.104.21]
> Nov 23 22:42:49 leuchtkanone postfix/smtpd[5863]: warning:
> mysql:/etc/postfix/sql/recipient-access.cf: table lookup problem
> Nov 23 22:42:49 leuchtkanone postfix/smtpd[5863]: NOQUEUE: reject:
> RCPT from divmail1.helmholtz-berlin.de[134.30.104.21]: 451 4.3.5
> : Recipient address rejected: Server configuration
> error; from= to=
> proto=ESMTP helo=
>
> I used this empty test procedure (query = CALL ret_empty;):
>
> CREATE DEFINER=`vmail`@`localhost` PROCEDURE `ret_empty`()
> BEGIN
> END
>
> In my procedure I had some code paths return a result and some not.
> Like I said i'm now using "SELECT 1 FROM dual WHERE false;" for those
> dead paths, this simulates the behavior of the previous solution (one
> line query) which always returns a result set, even if it's empty.

Joel

with MySQL procedures every SELECT statement that is executed produces a
result set. In my patch I explicitly check to make sure there are no
multiple result sets, but I do not check for no result. That could be
improved upon, to give a specific warning that no result sets were
returned. However, that will always be a lookup failure. The stored
procedure (based on the way the patch is written) must always return a
result set even if that result set is empty.

Your solution with returning an empty result set when there is no other
result (SELECT 1 FROM DUAL WHERE FALSE) looks correct.

John