Re: postfix-tls error

[Viktor Dukhovni]

On Thu, Aug 03, 2017 at 12:19:55PM +0530, hyndavirap...@bel.co.in wrote:

> > He's not posted the configuration of the sending system or
> > its logs.  This is a waste of everyone's time.

The relevant logging is the TLS-related logging from the sending
postfix/smtp client process that happens *before* the message is
finally deferred and is enabled via smtp_tls_loglevel=1.

> smtp_enforce_tls = yes

Instead, "smtp_tls_security_level = encrypt".

> smtp_tls_loglevel = 1
> smtp_tls_policy_maps = hash:/etc/postfix/tls_policy

Post the relevant tls policy table entry.

> smtp_use_tls = yes

This is unnecessary.

> transport_maps = hash:/etc/postfix/transportmap
> 
> Aug  3 12:11:54 AHQ postfix/smtp[8325]: 4B68168543FC:
> to=, orig_to=,
> relay=201.123.1.4[201.123.1.4]:25, delay=34, delays=34/0/0/0, dsn=4.7.5,
> status=deferred (Server certificate not verified)

The server certificate failed to verify.  Perhaps expired, perhaps
not issued by the CA you've configured, or a missing intermediate
certificate, or the certificate is not suitable for TLS (maybe it
has some other extended key usage), or ...

> Can you help me to solve this problem

Not without the requested logging, and copy of the server and CA
certificates.

-- 
Viktor.

Re: Why there is no `reject_rbl_sender` restriction?

[Wietse Venema]

Martin Ji?i?ka:
> > Did you mean: reject_rhsbl_sender (i.e. reject the sender domain)?
> > That already exists.
> 
> The `reject_rhsbl_sender` checks whether MAIL FROM domain is listed
> under rbl_domain. And I would like to have `reject_rbl_sender` that
> would check whether reversed sender domain is listed under rbl_domain.
> In other words, as there are `reject_rhsbl_client` and
> `reject_rbl_client` restrictions, analogously I would like to have
> `reject_rhsbl_sender` AND `reject_rbl_sender`.
> 
> Reason is I have found out that very very often my uncaught spam have
> MAIL FROM domain that is not listed under dbl.spamhaus.org, but its
> reversed address is listed under zen.spamhaus.org. I gave example with
> "spplalru.com" domain.

We already have check_mumble_mx_access and check_mumble_ns_access
to map a domain name to a collection of IP addresses.

It seems natural (for me at least) to introduce a new map type
dnsbl: that maps those IP addresses to an action.

Example:
check_sender_mx_access dnsbl:zen.spamhaus.org=127.0.0.1
check_client_ns_access dnsbl:zen.spamhaus.org=127.0.0.1

In case somoeone runs their DNS or MX service off a botnet.

Wietse

Re: Why there is no `reject_rbl_sender` restriction?

[Martin Jiřička]

> I'm not talking about DNS lookups, but about DNSBL lookups.

Yes, I did interchanged them, pardon.

> You ask each dnsbl for client IP, now you will ask them for each A or MX
> record. That means, number of DNSBL lookups will increase ad least two times
> (for each dnsbl you already query).

Hmm, I am not server administrator by profession, so maybe I do not
understand it enough, but I would only add one more restriction on
domain in MAIL FROM header, that would make one DNS lookup (getting IP
for the domain) and one DNSBL lookup (checking that IP in Spamhaus).
That are two lookups, aren't they? It is true that it is not clear
whether to get A or MX records for the domain. For my example the
blacklisted IP address is within A record. I guess there is usually
only one A record for each domain?

> Note that some dnsbls require (payed) subscription if you use them too much.

This is my first mail server so I need to check which restrictions
work best. Then I will optimize number and order of restrictions.

> we aren't talking about domains, but IP addresses of servers the domains
> point to, correct?

I think Allen spoke about domains. So did I. It is probably true that
building blacklist of IP addresses would be better idea than building
list of domains. Because I guess spammers have more domains than IP
addresses…

Re: Why there is no `reject_rbl_sender` restriction?

[Matus UHLAR - fantomas]

Doing it on MX would require dnsbl lookups for each MX server in all
received mail.
That would massively increase amount of dnsbl lookups.


On 03.08.17 13:38, Martin Jiřička wrote:

I do not know if I would call it "massively". I already do
`reject_unknown_client_hostname` check and 4 other dnsbl lookups. So I
would do another 2 in addition to current 5? Yes, it is a lot, but
thats how it is… My server does not serve a huge amount of real mail
fortunately.


I'm not talking about DNS lookups, but about DNSBL lookups.
You ask each dnsbl for client IP, now you will ask them for each A or MX
record. That means, number of DNSBL lookups will increase ad least two times
(for each dnsbl you already query).

Note that some dnsbls require (payed) subscription if you use them too much.


you still can block them locally using the rules above.


I think it will not work, almost every spam comes from different domain.


we aren't talking about domains, but IP addresses of servers the domains
point to, correct?

--
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.
"To Boot or not to Boot, that's the question." [WD1270 Caviar]

Re: NOTIFY=SUCCESS in Milter

[Matus UHLAR - fantomas]

Am 03.08.2017 um 07:32 schrieb Tomas Macek:

I'm trying to get to know, if there is a chance to see in Milter that the 
"NOTIFY=xxx,yyy,zzz" was specified by a client at rcpt to command



On Thu, 3 Aug 2017, A. Schulze wrote:

from the milter API Doku:

xxfi_envrcpt:
ctx Opaque context structure.
argvNull-terminated SMTP command arguments; argv[0] is guaranteed to be the 
recipient address. Later arguments are the ESMTP arguments.

The "Later arguments are the ESMTP arguments" is your "hope" ...
but I never tested/used that.


On 03.08.17 14:09, Tomas Macek wrote:

This is a relevant piece from my log:

mlfi_envrcpt: argv[0] = , argv[1] = 
NOTIFY=SUCCESS,FAILURE,DELAY

So I'm writing a Milter to tackle the spammers my own way!


just for curiosity: under what circumstances are you going to drop NOTIFY
parameters?
because, postfix can do this per sending IP

I'd prefer patch to amavisd-milter if possible ;-)

--
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.
Microsoft dick is soft to do no harm

Re: Why there is no `reject_rbl_sender` restriction?

[Martin Jiřička]

> Did you mean: reject_rhsbl_sender (i.e. reject the sender domain)?
> That already exists.

The `reject_rhsbl_sender` checks whether MAIL FROM domain is listed
under rbl_domain. And I would like to have `reject_rbl_sender` that
would check whether reversed sender domain is listed under rbl_domain.
In other words, as there are `reject_rhsbl_client` and
`reject_rbl_client` restrictions, analogously I would like to have
`reject_rhsbl_sender` AND `reject_rbl_sender`.

Reason is I have found out that very very often my uncaught spam have
MAIL FROM domain that is not listed under dbl.spamhaus.org, but its
reversed address is listed under zen.spamhaus.org. I gave example with
"spplalru.com" domain.

Re: Why there is no `reject_rbl_sender` restriction?

[Wietse Venema]

Martin Ji?i?ka:
> Hi,
> 
> why there is no `reject_rbl_sender` restriction?

Did you mean: reject_rhsbl_sender (i.e. reject the sender domain)?
That already exists.

Wietse

Re: NOTIFY=SUCCESS in Milter

[Tomas Macek]

On Thu, 3 Aug 2017, A. Schulze wrote:




Am 03.08.2017 um 07:32 schrieb Tomas Macek:


I'm trying to get to know, if there is a chance to see in Milter that the 
"NOTIFY=xxx,yyy,zzz" was specified by a client at rcpt to command


Hello Tomas,

from the milter API Doku:

xxfi_envrcpt:
 ctxOpaque context structure.
 argv   Null-terminated SMTP command arguments; argv[0] is guaranteed to be the 
recipient address. Later arguments are the ESMTP arguments.

The "Later arguments are the ESMTP arguments" is your "hope" ...
but I never tested/used that.

Andreas



Hello Andreas,

you are right!

This is a relevant piece from my log:

mlfi_envrcpt: argv[0] = , argv[1] = 
NOTIFY=SUCCESS,FAILURE,DELAY

So I'm writing a Milter to tackle the spammers my own way!

Thank you!

Tomas

Re: Why there is no `reject_rbl_sender` restriction?

[Allen Coates]

On 03/08/17 11:55, Matus UHLAR - fantomas wrote:
> You apparently mean something like check_sender_mx_access (reject when MX
> server of sending domain points to blacklisted IP) or maybe
> check_sender_a_access (similar), but with dnsbl lookups.
>
> Doing it on MX would require dnsbl lookups for each MX server in all
> received mail.
> That would massively increase amount of dnsbl lookups.
>
> Doing it on A would do the same, just not that much.

Do it after a white-list of senders you know

Allen C

Re: Why there is no `reject_rbl_sender` restriction?

[Martin Jiřička]

> Doing it on MX would require dnsbl lookups for each MX server in all
> received mail.
> That would massively increase amount of dnsbl lookups.

I do not know if I would call it "massively". I already do
`reject_unknown_client_hostname` check and 4 other dnsbl lookups. So I
would do another 2 in addition to current 5? Yes, it is a lot, but
thats how it is… My server does not serve a huge amount of real mail
fortunately.

> you still can block them locally using the rules above.

I think it will not work, almost every spam comes from different domain.

> On 03.08.17 11:09, Allen Coates wrote:
>> Using the whole email address didn't work - I never sawthe same sender
>> twice;

Yes, exactly. Spammers have huge amount of hostnames.

I do not think it is a good idea to build your own database. I even do
not know how to build it, because I do not run MDA, I only forward
emails… Simply put: I think it is difficult to fight against global
botnets with a local black list :-)


MJ

Re: Why there is no `reject_rbl_sender` restriction?

[Matus UHLAR - fantomas]

On 03.08.17 11:07, Martin Jiřička wrote:

why there is no `reject_rbl_sender` restriction? It probably does not
make so much sense as `reject_rbl_client`, but it would help me in my
spam battle. Quite a lot of emails come from servers not listed inside
Spamhause blacklists, but sender's domain points to blacklisted IP.


You apparently mean something like check_sender_mx_access (reject when MX
server of sending domain points to blacklisted IP) or maybe
check_sender_a_access (similar), but with dnsbl lookups.

Doing it on MX would require dnsbl lookups for each MX server in all
received mail.
That would massively increase amount of dnsbl lookups.

Doing it on A would do the same, just not that much.


For example yesterday came email from: Jaromil
 from client: bounce.countrcultur.com
[66.45.255.215]



Host spplalru.com.dbl.spamhaus.org not found: 3(NXDOMAIN)



spplalru.com has address 185.140.110.3



3.110.140.185.zen.spamhaus.org has address 127.0.0.2


you still can block them locally using the rules above.

On 03.08.17 11:09, Allen Coates wrote:

For a while I tried a local black-list based on the senders of bounced
emails. It was deployed using "check_sender_access ".

Using the whole email address didn't work - I never sawthe same sender
twice;
and using just the domain part gave me more false positives than true.


this is the keyword: false positives.

--
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.
We are but packets in the Internet of life (userfriendly.org)

Re: Why there is no `reject_rbl_sender` restriction?

[Allen Coates]

For a while I tried a local black-list based on the senders of bounced
emails. It was deployed using "check_sender_access ".

Using the whole email address didn't work - I never sawthe same sender
twice;
and using just the domain part gave me more false positives than true.

A more targeted list, containing PROVEN dud domains and reserved TLDs -
example.com or invalid.net - might have more success.  I haven't given
up on the idea completely.  :-)
 
Not quite what you asked - but it might help to explain


Allen C


On 03/08/17 10:07, Martin Jiřička wrote:
> Hi,
>
> why there is no `reject_rbl_sender` restriction? It probably does not
> make so much sense as `reject_rbl_client`, but it would help me in my
> spam battle. Quite a lot of emails come from servers not listed inside
> Spamhause blacklists, but sender's domain points to blacklisted IP.
>
> For example yesterday came email from: Jaromil
>  from client: bounce.countrcultur.com
> [66.45.255.215]
>
> Client is not blacklisted under Spamhaus, but lets have a look in more
> detail to sender.
>
> # Domain is not listed:
>> host spplalru.com.dbl.spamhaus.org
> Host spplalru.com.dbl.spamhaus.org not found: 3(NXDOMAIN)
>
> # Check for IP:
>> host spplalru.com
> spplalru.com has address 185.140.110.3
>
> # But the domain point on blacklisted server!
>> host 3.110.140.185.zen.spamhaus.org
> 3.110.140.185.zen.spamhaus.org has address 127.0.0.2
>
>
> And this is not a unique case! In fact most of spam that pass my
> anti-spam setting would be filtered with such restriction according
> sender domain. Maybe it is more problem of Spamhaus and its list
> synchronization, I do not know.
>
> Or is there any fundamental reason why rejecting emails according
> sender's domain IP is not a good idea?
>
>
> My best wishes,
> Martin Jiřička
>

Re: NOTIFY=SUCCESS in Milter

[A. Schulze]

Am 03.08.2017 um 07:32 schrieb Tomas Macek:

> I'm trying to get to know, if there is a chance to see in Milter that the 
> "NOTIFY=xxx,yyy,zzz" was specified by a client at rcpt to command

Hello Tomas,

from the milter API Doku:

xxfi_envrcpt:
  ctx   Opaque context structure.
  argv  Null-terminated SMTP command arguments; argv[0] is guaranteed to be the 
recipient address. Later arguments are the ESMTP arguments. 

The "Later arguments are the ESMTP arguments" is your "hope" ...
but I never tested/used that.

Andreas

Why there is no `reject_rbl_sender` restriction?

[Martin Jiřička]

Hi,

why there is no `reject_rbl_sender` restriction? It probably does not
make so much sense as `reject_rbl_client`, but it would help me in my
spam battle. Quite a lot of emails come from servers not listed inside
Spamhause blacklists, but sender's domain points to blacklisted IP.

For example yesterday came email from: Jaromil
 from client: bounce.countrcultur.com
[66.45.255.215]

Client is not blacklisted under Spamhaus, but lets have a look in more
detail to sender.

# Domain is not listed:
> host spplalru.com.dbl.spamhaus.org
Host spplalru.com.dbl.spamhaus.org not found: 3(NXDOMAIN)

# Check for IP:
> host spplalru.com
spplalru.com has address 185.140.110.3

# But the domain point on blacklisted server!
> host 3.110.140.185.zen.spamhaus.org
3.110.140.185.zen.spamhaus.org has address 127.0.0.2


And this is not a unique case! In fact most of spam that pass my
anti-spam setting would be filtered with such restriction according
sender domain. Maybe it is more problem of Spamhaus and its list
synchronization, I do not know.

Or is there any fundamental reason why rejecting emails according
sender's domain IP is not a good idea?


My best wishes,
Martin Jiřička

Re: Is it possible to suppress NDR/Delayed delivery messages generated by messages to a particular RCPT?

[Tobi]

Am 02.08.2017 um 12:59 schrieb Wietse Venema:
> Why mess with NDRs, when you could reduce the intensity of the flow
> to the mbox servers?
> 

As usual thanks to Wietse for putting me in the right direction. :-)
It was not the amount of msg but the message size itself which was
problematic.

My sieve script calls external commands (my scripts) to parse out urls
from content and ips from received headers for such messages. After
looking at the queue I saw that messages which stuck were always bigger
than 2mb
So looking deeper at my scripts I found that they were very slow in
reading the message from stdin. After optimizing the read from stdin and
some other little changes even huge messages are now processed in quite
short time.
My scripts now use only the first 1024 lines from message content to
look for urls instead the whole content. And in sieve script I added a
size limit that messages over 2mb are not even passed to my scripts

Again thanks for your help Wietse

Cheers

tobi

Re: postfix-tls error

[hyndavirapuru]

> On Wed, Aug 02, 2017 at 10:00:58AM -0500, Noel Jones wrote:
>
>> >> smtpd_tls_loglevel = 2
>> >
>> > Change that to 1, and also set:
>> >
>> > smtp_tls_security_level = 1
>>
>>
>> Oops, that should be
>>
>>smtp_tls_loglevel = 1
>
> Indeed a typo, thanks for the corection, ... and then the OP must
> *POST* the resulting logging.
>
> He's not posted the configuration of the sending system or
> its logs.  This is a waste of everyone's time.
>
> --
>   Viktor.
>


Hi viktor,


By mistake, i have posted receiving server configuration.

Below is the configuration of the sending system


bounce_queue_lifetime = 40s
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
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
html_directory = no
inet_interfaces = all
inet_protocols = all
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
maximal_queue_lifetime = 8h
mydestination = $myhostname.$mydomain,$myhostname, $myhostname,
localhost.localdomain
mydomain = tcs.mil.in
myhostname = AHQserver.tcs.mil.in
mynetworks = 127.0.0.0/8, 201.123.80.0/24, 201.123.1.0/24, 201.123.2.0/24
mynetworks_style = subnet
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
queue_run_delay = 30s
readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES
sample_directory = /usr/share/doc/postfix-2.6.6/samples
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtp_enforce_tls = yes
smtp_tls_CAfile = /etc/new_pki/tls/certs/ca-bundle.crt
smtp_tls_loglevel = 1
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
smtp_use_tls = yes
smtpd_starttls_timeout = 300s
smtpd_tls_CApath = /root/hyndavi/certs
smtpd_tls_ask_ccert = no
smtpd_tls_auth_only = no
smtpd_tls_cert_file = /root/hyndavi/certs/ahq_smtp_ad...@tcs.mil.in.pem
smtpd_tls_key_file = /root/hyndavi/certs/ahq_smtp_ad...@tcs.mil.in.key
smtpd_tls_security_level = encrypt
transport_maps = hash:/etc/postfix/transportmap
unknown_local_recipient_reject_code = 550
virtual_alias_maps = ldap:/etc/postfix/virtual_alias_map_ldapusers,
ldap:/etc/postfix/ldapdistlist.cf
virtual_gid_maps = static:5000
virtual_mailbox_base = /var/mail/vmail
virtual_mailbox_domains = AHQ.tcs.mil.in
virtual_mailbox_maps = ldap:/etc/postfix/virtual_mailbox_ldapusers
virtual_minimum_uid = 1000
virtual_uid_maps = static:5000


As i have already told ca-bundle.crt is having ca certificate. Both the
sending and receiving server certificates have been generated with the
same CA certificate. CA is a self signed certificate.

After doing configuration changes whatever have been suggested, I have
sent mail from AHQ server to 1CorpHQ server. below is the Log

Aug  3 12:11:54 AHQ postfix/smtp[8325]: 4B68168543FC:
to=, orig_to=,
relay=201.123.1.4[201.123.1.4]:25, delay=34, delays=34/0/0/0, dsn=4.7.5,
status=deferred (Server certificate not verified)

Can you help me to solve this problem


-- 
Thanks & Regards
Hyndavi rapuru
Member( Research Staff)
Central Research Laboratory
Bharat Electronics Ltd
Jalahalli
Bangalore- 560 013

Int Ph No: 134
Off Ph No: 080-28381125
Off Fax No: 28381168


कागज़ के 3000 पन्नों के लिए एक पेड़ को काटा जाता है... पेड़ बचाएँ... पेड़ों का 
संरक्षण करें... हरियाली लाएँ... इस मेल का या इसकी किसी फाइल का प्रिंट तब तक न 
लें जब तक सचमुच ज़रूरत न हो 
 

Every 3000 Sheets of paper costs us a tree.. Save trees... Conserve 
Trees. Don't print this email or any Files unless you really need to 

Confidentiality Notice/गोपनीय सूचना 

इस इलेक्ट्रॉनिक संदेश में शामिल जानकारी और इस संदेश के साथ दिया गया संलग्नक 
केवल 
प्रेषिती के अनन्य इस्तेमाल के लिए है और इसमें गोपनीय या विशेषाधिकार प्राप्त 
जानकारी
शामिल हो सकती है । यदि आप आशयित प्राप्तकर्ता नहीं हैं, तो कृपया तुरंत भारत 
इलेक्ट्रॉनिक्स के प्रेषक को बताएँ 
या supp...@bel.co.in पर मेल द्वारा सूचित करें और इस संदेश की सभी प्रतियाँ और 
उसके साथ लगे संलग्नकों को नष्ट कर दें । 
The information contained in this electronic message and any 
attachments to this message are intended for the exclusive use of
the addressee(s) and may contain confidential or privileged 
information. If you are not the intended recipient, please notify
the sender at Bharat Electronics  or supp...@bel.co.in immediately
and destroy all copies of this message and any attachments.