Re: SV: access permissions 101

2016-02-19 Thread Michael Orlitzky 
On 02/19/2016 08:05 PM, Sebastian Nielsen wrote:
> 
> Yeah, I agree that actually, only 644 is required on that config
> file. But why get so angry when someone 666's a file to just get
> things working? Its not like a list of banned spam domains is
> something super-sensitive.
> 

Maybe this makes a good case in point. Your "list of banned spam
domains" is actually whatever an attacker would like to feed into
check_sender_access. For example, your domain name was registered with
Gandi. Anyone who can execute *anything* on your server can now redirect
all Gandi emails to himself, reset the password on your account, and
take over every domain you own.

SV: access permissions 101

2016-02-19 Thread Sebastian Nielsen 
Everytime I need multiple processes to access the very same file and those 
processes has interlocks that prevent them from running as the same user or 
same group, I just "fix" the problem with 666.

That is a thing I ONLY do if I get a permission error when trying to do 
something I want to do with some software. So for example, when I want to edit 
something from my admin panel on http://www.sebbe.eu , I just 666 that file to 
be able to access it from the admin panel.

Same, I needed to get arp working so HTTP could execute arp for detecting which 
MAC addresses users of a captive portal had. I simply 777'd arp command, 
because not even 755 worked for some reason, the arp command required whoever 
that had execute permission to also have write permission.

Yeah, I agree that actually, only 644 is required on that config file. But why 
get so angry when someone 666's a file to just get things working?
Its not like a list of banned spam domains is something super-sensitive.


-Ursprungligt meddelande-
Från: Jim Reid [mailto:j...@rfc1035.com] 
Skickat: den 20 februari 2016 01:40
Till: Sebastian Nielsen 
Kopia: postfix-users@postfix.org
Ämne: access permissions 101


> On 19 Feb 2016, at 23:52, Sebastian Nielsen  wrote:
> 
> but if you're hosting for example a mail server for a company, and only you 
> as a sysadmin has shell access to the server, its no danger 666'ing files 
> that throw permission errors. Then the file isn't really "world writable", 
> since only you have a account on the server anyways.

This is a remarkably stupid and utterly irresponsible thing to say. It’s also 
wrong. Very, very wrong.

One of the fundamental principles of security is least privilege. Things get 
the minimum permissions/access rights/whatever that are needed for the task 
they have to perform.

So for postfix only some postfix processes need to have write access from time 
to time to specific files and directories. Almost nothing should ever need 
write access to postfix's configuration files, except for maybe postmap when 
rebuilding hash tables. So postfix's config files shouldn’t be writable by 
anyone, not even the postfix user.

Your starting assumption is also deeply flawed. A world-writable file can be 
written to by anything, not just the UIDs who have shell accounts. There will 
be other (or should be) UIDs and GIDs allocated to other services that run on 
the box: HTTP, DNS, printing, MySQL, postgres, games, spam filters, man pages, 
TeX, FTP, etc, etc. That way if one of these things has a security leak, it can 
only write to that UID’s writable files (if there are any). The breakage can’t 
contaminate anything else. But if someone is stupid enough to intentionally 
make config files world-writable, these can be damaged by a security problem in 
a rogue application. This is why the TeX user (say) doesn’t get write access to 
the DNS or mail or MySQl or configuration. That UID doesn’t need those 
privileges. So it doesn’t get them. At least, not on any sensibly managed 
computer system.

The logical extension of your approach is to make the password file, kernel, 
shared library, etc world-writable. After all, you’re the only one who has 
shell access. And you never, ever make mistakes and no software vulnerabilities 
of any sort ever occur on the servers you manage - right?

If you were hosting mail for my business and I found out you’d *deliberately* 
set 666 permissions on the mail configuration files my company depended on, I’d 
sue you for gross negligence. And win.





smime.p7s
Description: S/MIME Cryptographic Signature

access permissions 101

2016-02-19 Thread Jim Reid 

> On 19 Feb 2016, at 23:52, Sebastian Nielsen  wrote:
> 
> but if you're hosting for example a mail server for a company, and only you 
> as a sysadmin has shell access to the server, its no danger 666'ing files 
> that throw permission errors. Then the file isn't really "world writable", 
> since only you have a account on the server anyways.

This is a remarkably stupid and utterly irresponsible thing to say. It’s also 
wrong. Very, very wrong.

One of the fundamental principles of security is least privilege. Things get 
the minimum permissions/access rights/whatever that are needed for the task 
they have to perform.

So for postfix only some postfix processes need to have write access from time 
to time to specific files and directories. Almost nothing should ever need 
write access to postfix's configuration files, except for maybe postmap when 
rebuilding hash tables. So postfix's config files shouldn’t be writable by 
anyone, not even the postfix user.

Your starting assumption is also deeply flawed. A world-writable file can be 
written to by anything, not just the UIDs who have shell accounts. There will 
be other (or should be) UIDs and GIDs allocated to other services that run on 
the box: HTTP, DNS, printing, MySQL, postgres, games, spam filters, man pages, 
TeX, FTP, etc, etc. That way if one of these things has a security leak, it can 
only write to that UID’s writable files (if there are any). The breakage can’t 
contaminate anything else. But if someone is stupid enough to intentionally 
make config files world-writable, these can be damaged by a security problem in 
a rogue application. This is why the TeX user (say) doesn’t get write access to 
the DNS or mail or MySQl or configuration. That UID doesn’t need those 
privileges. So it doesn’t get them. At least, not on any sensibly managed 
computer system.

The logical extension of your approach is to make the password file, kernel, 
shared library, etc world-writable. After all, you’re the only one who has 
shell access. And you never, ever make mistakes and no software vulnerabilities 
of any sort ever occur on the servers you manage - right?

If you were hosting mail for my business and I found out you’d *deliberately* 
set 666 permissions on the mail configuration files my company depended on, I’d 
sue you for gross negligence. And win.

Re: Protection for Forwarding Loop

2016-02-19 Thread Atnakus Arzah 

On Sat, Feb 20, 2016 at 12:53:29AM +0200, Andreas Krischer - akbyte wrote:

So my question is: is their any possibility that postfix can detect
forwarding loops and just stop them? No matter on all the LDAP stuff,
shouldn't postfix be intelligent enough to detect if forwarding source
and destination are similar?

It would be great, if someone has an idea how we could solve this!


Have you explored using smtp_header_checks to set a header in outgoing
email and checking for that header using milter_header_checks. Just a
suggestion.

--
Atnakus Arzah 

When in doubt, have a cookie!

Re: SV: SV: Blocking TLDs

2016-02-19 Thread Michael Orlitzky 
On 02/19/2016 06:52 PM, Sebastian Nielsen wrote:
> 
> 2: Its just a habit, everytime some process complains of not able to
> access a file, "666" is the universal solution. Of course, this isn't
> recommended in a web hosting setup, but if you're hosting for example
> a mail server for a company, and only you as a sysadmin has shell
> access to the server, its no danger 666'ing files that throw
> permission errors. Then the file isn't really "world writable", since
> only you have a account on the server anyways.
> 

There are two problems with this. First, you are never the only user in
/etc/passwd. Those other accounts belong to services potentially acting
on behalf of other people, and now they can overwrite your files.

But more importantly: when you need to add a second shell account for an
intern five years from now, did you keep track of every single file that
you changed to mode 666? Whoops, your intern has root.

Re: Bounce on Postfix Pipe Command Execution Failure

2016-02-19 Thread Wietse Venema 
Reid Sutherland:
[ Charset ISO-8859-1 converted... ]
> Wietse Venema wrote:
> >>> I don't think that it is a good idea to fill up your machine with
> >>> programs that keep timing out again and again and again. Postfix
> >>> is not only about performance and security, but also about safety
> >>> (mail servers should be able to deal with problems and not require
> >>> a human babysitter).
> >>
> >> Understood, but if this condition is occurring, there must be delay or
> >> failure in another component of the system.
> >
> > Obviously, there is a failure of some kind, and absent a human
> > operator to click on OK/ABORT/RETRY, the mail system has to choose
> > a safe action.
> >
> > Unsafe actions lead to system congestion and human operators
> > having to unclog the toilet.
> >
> 
> 
> But it transfers the burden back onto the sender to recreate the message 
> and hope it arrives.  Their tension will grow each time it bounces back 
> to them.
> 
> The admin can monitor queue sizes and state to determine what's going 
> on.  They can also monitor the rest of the system to know why mail is 
> piling up.
> 
> 
> > If you prefer a mail system that needs a babysitter, don't use
> > Postfix.  I can't make recommendations about other mail systems.
> >
> 
> 
> Not asking for Postfix to babysit the problem, but to keep the already 
> queued message if an internal pipe problem is detected.
> 
> And no, I can't think of any other mail systems either.  I accept the 
> conditions of Postfix, just wanted to explain the problem we face.
> 
> Thank you again for your time.
>

Re: Blocking TLDs

2016-02-19 Thread yahoogroups 
Actually I have a xyz domain that mirrors my com domain. I use it for test 
purposes. 

Sent from my BlackBerry 10 smartphone.
  Original Message  
From: Sebastian Nielsen
Sent: Friday, February 19, 2016 3:53 PM
To: postfix-users@postfix.org
Subject: SV: SV: Blocking TLDs

1: REJECT tells the spammer "Hey, your spam got stuck in the spam filter. Wanna 
try again?".
Better to DISCARD it so the spammer think they got the spam through, then they 
won't switch to a new domain.

I don't think anyone ever will receive legitimate mail from any of those spammy 
TLDs listed in the rules file I gave.

2: Its just a habit, everytime some process complains of not able to access a 
file, "666" is the universal solution. Of course, this isn't recommended in a 
web hosting setup, but if you're hosting for example a mail server for a 
company, and only you as a sysadmin has shell access to the server, its no 
danger 666'ing files that throw permission errors. Then the file isn't really 
"world writable", since only you have a account on the server anyways.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För A. Schulze
Skickat: den 19 februari 2016 23:52
Till: postfix-users@postfix.org
Ämne: Re: SV: Blocking TLDs


Sebastian Nielsen:

> Then paste all the DISCARD lines into a new file called 
> /etc/postfix/banned_tlds (and also add some own TLDs there, its just 
> to copy paste one line and then change the TLD), and also remove lines 
> for TLDs you don’t want to block.
>
> Chmod the banned_tlds file to 666 to ensure the postfix process can read it.

two annotations:
- I would not suggest DISCARD but REJECT
- mode 666 (world writable) is generally not needed. 644 is enough

Andreas

>
>
>
>
> Then do “service postfix restart”
>
> Then you should be all set.
>
>
>
> Test the permission by sending a email using a spoofed address in your 
> email software, to yourself. The mail will always be successfully sent, but:
>
> If all goes well, you should see in the logs that “DISCARD” action was 
> triggered, which means the mail will be tossed in the dustbin without 
> delivering it to you.
>
> Remember to return your email client to non-spoofed state after that, 
> for obvious reasons.
>
>
>
> Från: Wolfe, Robert [mailto:robert.wo...@robertwolfe.org]
> Skickat: den 19 februari 2016 23:19
> Till: 'Sebastian Nielsen' ; 
> postfix-users@postfix.org
> Ämne: RE: Blocking TLDs
>
>
>
> Just copy and passed the DISCARD contents into banned_tlds?
>
>
>
> From: owner-postfix-us...@postfix.org
> 
> [mailto:owner-postfix-us...@postfix.org] On Behalf Of Sebastian 
> Nielsen
> Sent: Friday, February 19, 2016 3:50 PM
> To: postfix-users@postfix.org 
> Subject: SV: Blocking TLDs
>
>
>
> smtpd_sender_restrictions = check_sender_access 
> pcre:/etc/postfix/banned_tlds
>
>
>
> banned_tlds:
>
> /\.bid$/ DISCARD
>
> /\.top$/ DISCARD
>
> /\.xyz$/ DISCARD
>
> /\.date$/ DISCARD
>
> /\.faith$/ DISCARD
>
> /\.download$/ DISCARD
>
>
>
>
>
> Problem solved.
>
>
>
>
>
> Från: owner-postfix-us...@postfix.org
> 
> [mailto:owner-postfix-us...@postfix.org] För Wolfe, Robert
> Skickat: den 19 februari 2016 22:36
> Till: postfix-users@postfix.org 
> Ämne: Blocking TLDs
>
>
>
> Greetings all!
>
>
>
> This is actually my first posting to the mailing list, but have 
> actually been following along on a regular basis and have learned 
> quite a bit of good things (and bad things *smiles*) about Postfix. 
> Unfortunately, I have one question that I am hoping someone here on the 
> mailing list can answer.
>
>
>
> I get a LOT of emails from domains that have *.download and *.xyz and 
> their TLDs and I was wondering if there was a way in Postfix that I 
> could block emails that are coming in from these (and other) TLDs at 
> the connection level?

SV: SV: Blocking TLDs

2016-02-19 Thread Sebastian Nielsen 
1: REJECT tells the spammer "Hey, your spam got stuck in the spam filter. Wanna 
try again?".
Better to DISCARD it so the spammer think they got the spam through, then they 
won't switch to a new domain.

I don't think anyone ever will receive legitimate mail from any of those spammy 
TLDs listed in the rules file I gave.

2: Its just a habit, everytime some process complains of not able to access a 
file, "666" is the universal solution. Of course, this isn't recommended in a 
web hosting setup, but if you're hosting for example a mail server for a 
company, and only you as a sysadmin has shell access to the server, its no 
danger 666'ing files that throw permission errors. Then the file isn't really 
"world writable", since only you have a account on the server anyways.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För A. Schulze
Skickat: den 19 februari 2016 23:52
Till: postfix-users@postfix.org
Ämne: Re: SV: Blocking TLDs


Sebastian Nielsen:

> Then paste all the DISCARD lines into a new file called 
> /etc/postfix/banned_tlds (and also add some own TLDs there, its just 
> to copy paste one line and then change the TLD), and also remove lines 
> for TLDs you don’t want to block.
>
> Chmod the banned_tlds file to 666 to ensure the postfix process can read it.

two annotations:
  - I would not suggest DISCARD but REJECT
  - mode 666 (world writable) is generally not needed. 644 is enough

Andreas

>
>
>
>
> Then do “service postfix restart”
>
> Then you should be all set.
>
>
>
> Test the permission by sending a email using a spoofed address in your 
> email software, to yourself. The mail will always be successfully sent, but:
>
> If all goes well, you should see in the logs that “DISCARD” action was 
> triggered, which means the mail will be tossed in the dustbin without 
> delivering it to you.
>
> Remember to return your email client to non-spoofed state after that, 
> for obvious reasons.
>
>
>
> Från: Wolfe, Robert [mailto:robert.wo...@robertwolfe.org]
> Skickat: den 19 februari 2016 23:19
> Till: 'Sebastian Nielsen' ; 
> postfix-users@postfix.org
> Ämne: RE: Blocking TLDs
>
>
>
> Just copy and passed the DISCARD contents into banned_tlds?
>
>
>
> From: owner-postfix-us...@postfix.org
> 
> [mailto:owner-postfix-us...@postfix.org] On Behalf Of Sebastian 
> Nielsen
> Sent: Friday, February 19, 2016 3:50 PM
> To: postfix-users@postfix.org 
> Subject: SV: Blocking TLDs
>
>
>
> smtpd_sender_restrictions = check_sender_access 
> pcre:/etc/postfix/banned_tlds
>
>
>
> banned_tlds:
>
> /\.bid$/ DISCARD
>
> /\.top$/ DISCARD
>
> /\.xyz$/ DISCARD
>
> /\.date$/ DISCARD
>
> /\.faith$/ DISCARD
>
> /\.download$/ DISCARD
>
>
>
>
>
> Problem solved.
>
>
>
>
>
> Från: owner-postfix-us...@postfix.org
> 
> [mailto:owner-postfix-us...@postfix.org] För Wolfe, Robert
> Skickat: den 19 februari 2016 22:36
> Till: postfix-users@postfix.org 
> Ämne: Blocking TLDs
>
>
>
> Greetings all!
>
>
>
> This is actually my first posting to the mailing list, but have 
> actually been following along on a regular basis and have learned 
> quite a bit of good things (and bad things *smiles*) about Postfix.  
> Unfortunately, I have one question that I am hoping someone here on the 
> mailing list can answer.
>
>
>
> I get a LOT of emails from domains that have *.download and *.xyz and 
> their TLDs and I was wondering if there was a way in Postfix that I 
> could block emails that are coming in from these (and other) TLDs at 
> the connection level?






smime.p7s
Description: S/MIME Cryptographic Signature

RE: SV: Blocking TLDs

2016-02-19 Thread Wolfe, Robert 
Followed this additional annotation and looks like everything is working here 
as it should.  Thanks to all who gave me the information I needed.

-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
On Behalf Of A. Schulze
Sent: Friday, February 19, 2016 4:52 PM
To: postfix-users@postfix.org
Subject: Re: SV: Blocking TLDs


Sebastian Nielsen:

> Then paste all the DISCARD lines into a new file called 
> /etc/postfix/banned_tlds (and also add some own TLDs there, its just 
> to copy paste one line and then change the TLD), and also remove lines 
> for TLDs you don’t want to block.
>
> Chmod the banned_tlds file to 666 to ensure the postfix process can read it.

two annotations:
  - I would not suggest DISCARD but REJECT
  - mode 666 (world writable) is generally not needed. 644 is enough

Andreas

>
>
>
>
> Then do “service postfix restart”
>
> Then you should be all set.
>
>
>
> Test the permission by sending a email using a spoofed address in your 
> email software, to yourself. The mail will always be successfully sent, but:
>
> If all goes well, you should see in the logs that “DISCARD” action was 
> triggered, which means the mail will be tossed in the dustbin without 
> delivering it to you.
>
> Remember to return your email client to non-spoofed state after that, 
> for obvious reasons.
>
>
>
> Från: Wolfe, Robert [mailto:robert.wo...@robertwolfe.org]
> Skickat: den 19 februari 2016 23:19
> Till: 'Sebastian Nielsen' ; 
> postfix-users@postfix.org
> Ämne: RE: Blocking TLDs
>
>
>
> Just copy and passed the DISCARD contents into banned_tlds?
>
>
>
> From: owner-postfix-us...@postfix.org
> 
> [mailto:owner-postfix-us...@postfix.org] On Behalf Of Sebastian 
> Nielsen
> Sent: Friday, February 19, 2016 3:50 PM
> To: postfix-users@postfix.org 
> Subject: SV: Blocking TLDs
>
>
>
> smtpd_sender_restrictions = check_sender_access 
> pcre:/etc/postfix/banned_tlds
>
>
>
> banned_tlds:
>
> /\.bid$/ DISCARD
>
> /\.top$/ DISCARD
>
> /\.xyz$/ DISCARD
>
> /\.date$/ DISCARD
>
> /\.faith$/ DISCARD
>
> /\.download$/ DISCARD
>
>
>
>
>
> Problem solved.
>
>
>
>
>
> Från: owner-postfix-us...@postfix.org
> 
> [mailto:owner-postfix-us...@postfix.org] För Wolfe, Robert
> Skickat: den 19 februari 2016 22:36
> Till: postfix-users@postfix.org 
> Ämne: Blocking TLDs
>
>
>
> Greetings all!
>
>
>
> This is actually my first posting to the mailing list, but have 
> actually been following along on a regular basis and have learned 
> quite a bit of good things (and bad things *smiles*) about Postfix.  
> Unfortunately, I have one question that I am hoping someone here on the 
> mailing list can answer.
>
>
>
> I get a LOT of emails from domains that have *.download and *.xyz and 
> their TLDs and I was wondering if there was a way in Postfix that I 
> could block emails that are coming in from these (and other) TLDs at 
> the connection level?

RE: SV: Blocking TLDs

2016-02-19 Thread Wolfe, Robert 
Noted.  Thank you muchly for this information :)  Filed away for future use :)

-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
On Behalf Of A. Schulze
Sent: Friday, February 19, 2016 4:52 PM
To: postfix-users@postfix.org
Subject: Re: SV: Blocking TLDs


Sebastian Nielsen:

> Then paste all the DISCARD lines into a new file called 
> /etc/postfix/banned_tlds (and also add some own TLDs there, its just 
> to copy paste one line and then change the TLD), and also remove lines 
> for TLDs you don’t want to block.
>
> Chmod the banned_tlds file to 666 to ensure the postfix process can read it.

two annotations:
  - I would not suggest DISCARD but REJECT
  - mode 666 (world writable) is generally not needed. 644 is enough

Andreas

>
>
>
>
> Then do “service postfix restart”
>
> Then you should be all set.
>
>
>
> Test the permission by sending a email using a spoofed address in your 
> email software, to yourself. The mail will always be successfully sent, but:
>
> If all goes well, you should see in the logs that “DISCARD” action was 
> triggered, which means the mail will be tossed in the dustbin without 
> delivering it to you.
>
> Remember to return your email client to non-spoofed state after that, 
> for obvious reasons.
>
>
>
> Från: Wolfe, Robert [mailto:robert.wo...@robertwolfe.org]
> Skickat: den 19 februari 2016 23:19
> Till: 'Sebastian Nielsen' ; 
> postfix-users@postfix.org
> Ämne: RE: Blocking TLDs
>
>
>
> Just copy and passed the DISCARD contents into banned_tlds?
>
>
>
> From: owner-postfix-us...@postfix.org
> 
> [mailto:owner-postfix-us...@postfix.org] On Behalf Of Sebastian 
> Nielsen
> Sent: Friday, February 19, 2016 3:50 PM
> To: postfix-users@postfix.org 
> Subject: SV: Blocking TLDs
>
>
>
> smtpd_sender_restrictions = check_sender_access 
> pcre:/etc/postfix/banned_tlds
>
>
>
> banned_tlds:
>
> /\.bid$/ DISCARD
>
> /\.top$/ DISCARD
>
> /\.xyz$/ DISCARD
>
> /\.date$/ DISCARD
>
> /\.faith$/ DISCARD
>
> /\.download$/ DISCARD
>
>
>
>
>
> Problem solved.
>
>
>
>
>
> Från: owner-postfix-us...@postfix.org
> 
> [mailto:owner-postfix-us...@postfix.org] För Wolfe, Robert
> Skickat: den 19 februari 2016 22:36
> Till: postfix-users@postfix.org 
> Ämne: Blocking TLDs
>
>
>
> Greetings all!
>
>
>
> This is actually my first posting to the mailing list, but have 
> actually been following along on a regular basis and have learned 
> quite a bit of good things (and bad things *smiles*) about Postfix.  
> Unfortunately, I have one question that I am hoping someone here on the 
> mailing list can answer.
>
>
>
> I get a LOT of emails from domains that have *.download and *.xyz and 
> their TLDs and I was wondering if there was a way in Postfix that I 
> could block emails that are coming in from these (and other) TLDs at 
> the connection level?

Protection for Forwarding Loop

2016-02-19 Thread Andreas Krischer - akbyte 
Hello dear postfix user!

I already asked on the German postfix-users-lists but nobody answered
there, so I hope, someone of you can help us :)

We have in a relatively large organization the following LDAP-Setup:

ou=users,dc=domain,dc=de contains all users with their attributes. We
use the `mail`-attribut always as final destination-address of the user.
If the user has a mailbox, it is the address of the mailbox. If the user
has a mail-alias, it's the forwarding destination.
Respective in last case we have the mail-address with @domain.de, which
should be forwarded, in `mailForwardingAddress`.

In order that postfix knows, who has an alias and who has a mailbox,
there are different users used in the different queries and everything
is filtered via LDAP-ACL (the permissions are managed with LDAP
`groupOfNames`).

That worked perfectly, but recently someone, who already had a mailbox,
added additionally an alias to this account. The result looked like this
in LDAP:
cn=einUser,ou=users,dc=domain,dc=de
mail: einu...@domain.de
mail: einu...@externalprovider.de
mailForwardingAddress: einu...@domain.de

You can imagine, was happened: when a mail to einu...@domain.de arrived
and postfix looked for aliases in LDAP, it found
einu...@externalprovider.de _and_ einu...@domain.de. This created an
infinitive loop, which could only be stopped with a postfix restart
(maybe it could be stopped in another way, but at the moment there were
no time for googling...)

We discussed intensive how to fix the problem: to pass on users with
mailbox and alias is unfortunately not possible. A LDAP-restructure goes
with a big effort, because many applications are connected to it, which
all have to be adapted. One option would be to just create two users -
one for alias and one for mailbox, but since we have our own
webinterface, where users can manage their accounts, this would be quite
elaborate to implement.

Certainly I searched already for a another solution, but I couldn't find
something.

So my question is: is their any possibility that postfix can detect
forwarding loops and just stop them? No matter on all the LDAP stuff,
shouldn't postfix be intelligent enough to detect if forwarding source
and destination are similar?

It would be great, if someone has an idea how we could solve this!

Cheers,
Andreas Krischer

akbyte webentwicklung
Pastor-Lüpschen-Str. 82
52351 Düren
https://akbyte.com
kont...@akbyte.com
+49 (0) 2421 500 332
Skype: akbyte_com




signature.asc
Description: OpenPGP digital signature

Re: SV: Blocking TLDs

2016-02-19 Thread A. Schulze 


Sebastian Nielsen:


Then paste all the DISCARD lines into a new file called
/etc/postfix/banned_tlds (and also add some own TLDs there, its just to copy
paste one line and then change the TLD), and also remove lines for TLDs you
don’t want to block.

Chmod the banned_tlds file to 666 to ensure the postfix process can read it.


two annotations:
 - I would not suggest DISCARD but REJECT
 - mode 666 (world writable) is generally not needed. 644 is enough

Andreas






Then do “service postfix restart”

Then you should be all set.



Test the permission by sending a email using a spoofed address in your email
software, to yourself. The mail will always be successfully sent, but:

If all goes well, you should see in the logs that “DISCARD” action was
triggered, which means the mail will be tossed in the dustbin without
delivering it to you.

Remember to return your email client to non-spoofed state after that, for
obvious reasons.



Från: Wolfe, Robert [mailto:robert.wo...@robertwolfe.org]
Skickat: den 19 februari 2016 23:19
Till: 'Sebastian Nielsen' ; postfix-users@postfix.org
Ämne: RE: Blocking TLDs



Just copy and passed the DISCARD contents into banned_tlds?



From: owner-postfix-us...@postfix.org

[mailto:owner-postfix-us...@postfix.org] On Behalf Of Sebastian Nielsen
Sent: Friday, February 19, 2016 3:50 PM
To: postfix-users@postfix.org 
Subject: SV: Blocking TLDs



smtpd_sender_restrictions = check_sender_access
pcre:/etc/postfix/banned_tlds



banned_tlds:

/\.bid$/ DISCARD

/\.top$/ DISCARD

/\.xyz$/ DISCARD

/\.date$/ DISCARD

/\.faith$/ DISCARD

/\.download$/ DISCARD





Problem solved.





Från: owner-postfix-us...@postfix.org

[mailto:owner-postfix-us...@postfix.org] För Wolfe, Robert
Skickat: den 19 februari 2016 22:36
Till: postfix-users@postfix.org 
Ämne: Blocking TLDs



Greetings all!



This is actually my first posting to the mailing list, but have actually
been following along on a regular basis and have learned quite a bit of good
things (and bad things *smiles*) about Postfix.  Unfortunately, I have one
question that I am hoping someone here on the mailing list can answer.



I get a LOT of emails from domains that have *.download and *.xyz and their
TLDs and I was wondering if there was a way in Postfix that I could block
emails that are coming in from these (and other) TLDs at the connection
level?

SV: Blocking TLDs

2016-02-19 Thread Sebastian Nielsen 
First add check_sender_access pcre:/etc/postfix/banned_tlds into
smtpd_sender_restrictions in main.cf

 

Then paste all the DISCARD lines into a new file called
/etc/postfix/banned_tlds (and also add some own TLDs there, its just to copy
paste one line and then change the TLD), and also remove lines for TLDs you
don’t want to block.

Chmod the banned_tlds file to 666 to ensure the postfix process can read it.


 

Then do “service postfix restart”

Then you should be all set.

 

Test the permission by sending a email using a spoofed address in your email
software, to yourself. The mail will always be successfully sent, but:

If all goes well, you should see in the logs that “DISCARD” action was
triggered, which means the mail will be tossed in the dustbin without
delivering it to you.

Remember to return your email client to non-spoofed state after that, for
obvious reasons.

 

Från: Wolfe, Robert [mailto:robert.wo...@robertwolfe.org] 
Skickat: den 19 februari 2016 23:19
Till: 'Sebastian Nielsen' ; postfix-users@postfix.org
Ämne: RE: Blocking TLDs

 

Just copy and passed the DISCARD contents into banned_tlds?

 

From: owner-postfix-us...@postfix.org

[mailto:owner-postfix-us...@postfix.org] On Behalf Of Sebastian Nielsen
Sent: Friday, February 19, 2016 3:50 PM
To: postfix-users@postfix.org  
Subject: SV: Blocking TLDs

 

smtpd_sender_restrictions = check_sender_access
pcre:/etc/postfix/banned_tlds

 

banned_tlds:

/\.bid$/ DISCARD

/\.top$/ DISCARD

/\.xyz$/ DISCARD

/\.date$/ DISCARD

/\.faith$/ DISCARD

/\.download$/ DISCARD

 

 

Problem solved.

 

 

Från: owner-postfix-us...@postfix.org

[mailto:owner-postfix-us...@postfix.org] För Wolfe, Robert
Skickat: den 19 februari 2016 22:36
Till: postfix-users@postfix.org  
Ämne: Blocking TLDs

 

Greetings all!

 

This is actually my first posting to the mailing list, but have actually
been following along on a regular basis and have learned quite a bit of good
things (and bad things *smiles*) about Postfix.  Unfortunately, I have one
question that I am hoping someone here on the mailing list can answer.

 

I get a LOT of emails from domains that have *.download and *.xyz and their
TLDs and I was wondering if there was a way in Postfix that I could block
emails that are coming in from these (and other) TLDs at the connection
level?



smime.p7s
Description: S/MIME Cryptographic Signature

RE: Blocking TLDs

2016-02-19 Thread Wolfe, Robert 
Just copy and passed the DISCARD contents into banned_tlds?

 

From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Sebastian Nielsen
Sent: Friday, February 19, 2016 3:50 PM
To: postfix-users@postfix.org
Subject: SV: Blocking TLDs

 

smtpd_sender_restrictions = check_sender_access
pcre:/etc/postfix/banned_tlds

 

banned_tlds:

/\.bid$/ DISCARD

/\.top$/ DISCARD

/\.xyz$/ DISCARD

/\.date$/ DISCARD

/\.faith$/ DISCARD

/\.download$/ DISCARD

 

 

Problem solved.

 

 

Från: owner-postfix-us...@postfix.org

[mailto:owner-postfix-us...@postfix.org] För Wolfe, Robert
Skickat: den 19 februari 2016 22:36
Till: postfix-users@postfix.org  
Ämne: Blocking TLDs

 

Greetings all!

 

This is actually my first posting to the mailing list, but have actually
been following along on a regular basis and have learned quite a bit of good
things (and bad things *smiles*) about Postfix.  Unfortunately, I have one
question that I am hoping someone here on the mailing list can answer.

 

I get a LOT of emails from domains that have *.download and *.xyz and their
TLDs and I was wondering if there was a way in Postfix that I could block
emails that are coming in from these (and other) TLDs at the connection
level?

Re: Bounce on Postfix Pipe Command Execution Failure

2016-02-19 Thread Reid Sutherland 

Wietse Venema wrote:

I don't think that it is a good idea to fill up your machine with
programs that keep timing out again and again and again. Postfix
is not only about performance and security, but also about safety
(mail servers should be able to deal with problems and not require
a human babysitter).


Understood, but if this condition is occurring, there must be delay or
failure in another component of the system.


Obviously, there is a failure of some kind, and absent a human
operator to click on OK/ABORT/RETRY, the mail system has to choose
a safe action.

Unsafe actions lead to system congestion and human operators
having to unclog the toilet.




But it transfers the burden back onto the sender to recreate the message 
and hope it arrives.  Their tension will grow each time it bounces back 
to them.


The admin can monitor queue sizes and state to determine what's going 
on.  They can also monitor the rest of the system to know why mail is 
piling up.




If you prefer a mail system that needs a babysitter, don't use
Postfix.  I can't make recommendations about other mail systems.




Not asking for Postfix to babysit the problem, but to keep the already 
queued message if an internal pipe problem is detected.


And no, I can't think of any other mail systems either.  I accept the 
conditions of Postfix, just wanted to explain the problem we face.


Thank you again for your time.

SV: Blocking TLDs

2016-02-19 Thread Sebastian Nielsen 
smtpd_sender_restrictions = check_sender_access
pcre:/etc/postfix/banned_tlds

 

banned_tlds:

/\.bid$/ DISCARD

/\.top$/ DISCARD

/\.xyz$/ DISCARD

/\.date$/ DISCARD

/\.faith$/ DISCARD

/\.download$/ DISCARD

 

 

Problem solved.

 

 

Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Wolfe, Robert
Skickat: den 19 februari 2016 22:36
Till: postfix-users@postfix.org
Ämne: Blocking TLDs

 

Greetings all!

 

This is actually my first posting to the mailing list, but have actually
been following along on a regular basis and have learned quite a bit of good
things (and bad things *smiles*) about Postfix.  Unfortunately, I have one
question that I am hoping someone here on the mailing list can answer.

 

I get a LOT of emails from domains that have *.download and *.xyz and their
TLDs and I was wondering if there was a way in Postfix that I could block
emails that are coming in from these (and other) TLDs at the connection
level?



smime.p7s
Description: S/MIME Cryptographic Signature

Blocking TLDs

2016-02-19 Thread Wolfe, Robert 
Greetings all!

 

This is actually my first posting to the mailing list, but have actually
been following along on a regular basis and have learned quite a bit of good
things (and bad things *smiles*) about Postfix.  Unfortunately, I have one
question that I am hoping someone here on the mailing list can answer.

 

I get a LOT of emails from domains that have *.download and *.xyz and their
TLDs and I was wondering if there was a way in Postfix that I could block
emails that are coming in from these (and other) TLDs at the connection
level?

Re: Bounce on Postfix Pipe Command Execution Failure

2016-02-19 Thread Wietse Venema 
Reid Sutherland:
> We also had to use the following hack to ensure module load failures do 
> not result in bounces.  I see that Unix::Syslog is absent from the this 
> list or the above bounce may have been prevented.

Indeed, if your program had returned a temporary error status,
Postfix would have queued the message for later delivery.  That is
the contract.

> >> or on command timeout?
> >
> > I don't think that it is a good idea to fill up your machine with
> > programs that keep timing out again and again and again. Postfix
> > is not only about performance and security, but also about safety
> > (mail servers should be able to deal with problems and not require
> > a human babysitter).
> 
> Understood, but if this condition is occurring, there must be delay or 
> failure in another component of the system.

Obviously, there is a failure of some kind, and absent a human
operator to click on OK/ABORT/RETRY, the mail system has to choose
a safe action. 

Unsafe actions lead to system congestion and human operators
having to unclog the toilet.

If you prefer a mail system that needs a babysitter, don't use
Postfix.  I can't make recommendations about other mail systems.

Wietse

Re: Bounce on Postfix Pipe Command Execution Failure

2016-02-19 Thread Reid Sutherland 

Wietse Venema wrote:

Reid Sutherland:

Hi,

Why does Postfix bounce on command execution failure,


The action depends on the command exit status. If you want Postfix
to retry, return the appropriate status.



Not fair, here was our problem:

Final-Recipient: rfc822; r...@vianet.ca
Original-Recipient: rfc822;s...@vianet.ca
Action: failed
Status: 5.3.0
Diagnostic-Code: x-unix; Can't load 
'/usr/lib/perl5/auto/Unix/Syslog/Syslog.so'
for module Unix::Syslog: /usr/lib/perl5/auto/Unix/Syslog/Syslog.so: 
failed

to map segment from shared object: Cannot allocate memory at
/usr/lib/perl/5.14/DynaLoader.pm line 184.  at 
/usr/local/bin/mailhandler
line 6 Compilation failed in require at /usr/local/bin/mailhandler 
line 6.

BEGIN failed--compilation aborted at /usr/local/bin/mailhandler line 6.


This is the result of an out-of-memory condition caused by a failing 
disk array.  The spawn count was set to high so the OOM condition was 
triggered.  While this was a mistake on our part, out of admin control 
execution failures should defer.


We also had to use the following hack to ensure module load failures do 
not result in bounces.  I see that Unix::Syslog is absent from the this 
list or the above bounce may have been prevented.



eval {
  require DBI;
  require Email::Simple::FromHandle;
  require CDB_File;
  require IPC::Open3;
};
my ($exit, $fail_temp, $fail_temp_ex, $fail_perm, $fail_quota_ex, 
$fail_loop_ex) = (0, 75, '4.3.0', 69, '5.2.2', '5.4.6');

if (!$@) {
  import DBI;
  import Email::Simple::FromHandle;
  import CDB_File;
  import IPC::Open3;
} else {
  warn "mailhandler: module load failed: $@";
  exit ($fail_temp);
}






or on command timeout?


I don't think that it is a good idea to fill up your machine with
programs that keep timing out again and again and again. Postfix
is not only about performance and security, but also about safety
(mail servers should be able to deal with problems and not require
a human babysitter).




Understood, but if this condition is occurring, there must be delay or 
failure in another component of the system.  This is assuming the system 
is in production and normally functioning.  It's too harsh to assume the 
timing out program is forever guilty of blocking the message.  Deferral 
seems reasonable because the admin must locate and correct the source of 
the delay.





  This isn't a situation for a hard failure, please clarify the
reasoning.

  From postfix-2.11.7/src/global/pipe_command.c:672

  } else if (write_status && write_errno != EPIPE) {
  vstring_prepend(why->reason, "Command failed: ",
  sizeof("Command failed: ") - 1);
  vstring_sprintf_append(why->reason, ": \"%s\"", args.command);
  return (PIPE_STAT_BOUNCE);


That is a write error, and the logfile tells you what the problem
is.  The write(2) may fail for a bazillion reasons, some bad and
some not so bad. Returning the mail is the safe action to take.




Sorry, this wasn't the correct snippet, but this was also of concern.  I 
think a local filesystem error would result in a deferral, I can't see 
why a command would be any different.


Here is the correct snippet from 
postfix-2.11.7/src/global/pipe_command.c:657:


/*
 * No "D.S.N text" or  compatible status. Fake it.
 */
else {
sp = sys_exits_detail(WEXITSTATUS(wait_status));
dsb_unix(why, sp->dsn,
 log_len ? log_buf : sp->text,
 "Command died with status %d: \"%s\"%s%s",
 WEXITSTATUS(wait_status), args.command,
 log_len ? ". Command output: " : "", log_buf);
return (PIPE_STAT_BOUNCE);
}



I think a bounce should only occur if the command explicitly returns it. 
 If the command cannot respond properly for whatever reason, it should 
be assumed something is wrong and defer.


Thank you for your time.

Re: Suppress logs for monitor connections

2016-02-19 Thread Wietse Venema 
Ray Dzek:
> We are load balancing our Postfix servers and as part of that there
> is a connection test to ensure the services are running. So the
> logs fill with connection checks. Is there a way to suppress those
> connections from the logs?

Even with one connect/disconnect event per second, the daily logfile
compression job would reduce those logfile records to just a few
hundred kilobytes (I get 15x compression with bzip2). On a busy
server the logging from the prober would be a drop in a bucket.

You can eliminate the logs with rsyslogd configuration. This was
discussed here only a day or so ago.

Wietse

Re: RBL look up errors

2016-02-19 Thread Ruben Safir 
On Fri, Feb 19, 2016 at 01:18:20PM -0600, Noel Jones wrote:
> On 2/19/2016 1:11 PM, Ruben Safir wrote:
> > Can aanyone clarify what this means?  it is happing a lot on my mail server
> > 
> > Feb 19 14:09:31 www postfix/smtpd[6978]: warning: 
> > 70.14.214.162.list.dsbl.org: RBL lookup error: Host or domain name not 
> > found. Name service error for name=70.14.214.162.list.dsbl.org type=A: Host 
> > not found, try again
> > 
> > 
> > 
> 
> 
> dsbl.org has been closed for 5+ years.  Remove it from your config.
> 


time flys ..

> 
> 
>   -- Noel Jones

-- 
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com 

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive 
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com 

Being so tracked is for FARM ANIMALS and and extermination camps, 
but incompatible with living as a free human being. -RI Safir 2013

Re: Suppress logs for monitor connections

2016-02-19 Thread Christian Kivalo 


Am 19. Februar 2016 20:32:20 MEZ, schrieb Ray Dzek :
>We are load balancing our Postfix servers and as part of that there is
>a connection test to ensure the services are running. So the logs fill
>with connection checks. Is there a way to suppress those connections
>from the logs?
Create a filter in your syslog daemon to remove your monitoring checks from the 
log stream

>Thanks in advance,
>
>Ray
-- 
 Christian

Re: Bounce on Postfix Pipe Command Execution Failure

2016-02-19 Thread Wietse Venema 
Reid Sutherland:
> Hi,
> 
> Why does Postfix bounce on command execution failure,

The action depends on the command exit status. If you want Postfix
to retry, return the appropriate status.

> or on command timeout?

I don't think that it is a good idea to fill up your machine with
programs that keep timing out again and again and again. Postfix
is not only about performance and security, but also about safety
(mail servers should be able to deal with problems and not require
a human babysitter).

>  This isn't a situation for a hard failure, please clarify the 
> reasoning.
> 
>  From postfix-2.11.7/src/global/pipe_command.c:672
> 
>  } else if (write_status && write_errno != EPIPE) {
>  vstring_prepend(why->reason, "Command failed: ",
>  sizeof("Command failed: ") - 1);
>  vstring_sprintf_append(why->reason, ": \"%s\"", args.command);
>  return (PIPE_STAT_BOUNCE);

That is a write error, and the logfile tells you what the problem
is.  The write(2) may fail for a bazillion reasons, some bad and
some not so bad. Returning the mail is the safe action to take.

Wietse

Suppress logs for monitor connections

2016-02-19 Thread Ray Dzek 
We are load balancing our Postfix servers and as part of that there is a 
connection test to ensure the services are running. So the logs fill with 
connection checks. Is there a way to suppress those connections from the logs?

Thanks in advance,

Ray

Re: RBL look up errors

2016-02-19 Thread Noel Jones 
On 2/19/2016 1:11 PM, Ruben Safir wrote:
> Can aanyone clarify what this means?  it is happing a lot on my mail server
> 
> Feb 19 14:09:31 www postfix/smtpd[6978]: warning: 
> 70.14.214.162.list.dsbl.org: RBL lookup error: Host or domain name not found. 
> Name service error for name=70.14.214.162.list.dsbl.org type=A: Host not 
> found, try again
> 
> 
> 


dsbl.org has been closed for 5+ years.  Remove it from your config.



  -- Noel Jones

RBL look up errors

2016-02-19 Thread Ruben Safir 
Can aanyone clarify what this means?  it is happing a lot on my mail server

Feb 19 14:09:31 www postfix/smtpd[6978]: warning: 70.14.214.162.list.dsbl.org: 
RBL lookup error: Host or domain name not found. Name service error for 
name=70.14.214.162.list.dsbl.org type=A: Host not found, try again



-- 
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com 

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive 
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com 

Being so tracked is for FARM ANIMALS and and extermination camps, 
but incompatible with living as a free human being. -RI Safir 2013

Bounce on Postfix Pipe Command Execution Failure

2016-02-19 Thread Reid Sutherland 

Hi,

Why does Postfix bounce on command execution failure, or on command 
timeout?  This isn't a situation for a hard failure, please clarify the 
reasoning.



From postfix-2.11.7/src/global/pipe_command.c:672

} else if (write_status && write_errno != EPIPE) {
vstring_prepend(why->reason, "Command failed: ",
sizeof("Command failed: ") - 1);
vstring_sprintf_append(why->reason, ": \"%s\"", args.command);
return (PIPE_STAT_BOUNCE);

Re: how to disable PLAIN authentication for unencrypted connections

2016-02-19 Thread Wietse Venema 
Udo Rader:
> Hi,
> 
> is there a possibility to only allow PLAIN authentication when TLS or
> similar encryption has been negotiated?
> 
> So far, I only found a way to either completely disable PLAIN
> authentication or allow it in general.

Postfix SMTP client:
smtp_sasl_security_options = noanonymous, noplaintext
smtp_sasl_tls_security_options = noanonymous

Postfix SMTP server:
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous

Wietse

how to disable PLAIN authentication for unencrypted connections

2016-02-19 Thread Udo Rader 
Hi,

is there a possibility to only allow PLAIN authentication when TLS or
similar encryption has been negotiated?

So far, I only found a way to either completely disable PLAIN
authentication or allow it in general.

Udo

Re: How to relay specific domain over TLS and rest all other without TLS ?

2016-02-19 Thread Viktor Dukhovni 
On Fri, Feb 19, 2016 at 02:55:45PM +0530, Jayesh Shinde wrote:

> I am doing this setting for sending email to  "aexp.com" .
> w.r.t  above info and docs i made below setting , but remote host saying
> "530 Must issue a STARTTLS command first."

The lookup key for the TLS policy table MUST match the verbatim
nexthop for the destination.  If you're using transport tables to
send the traffic via a designated relay, the lookup key must match
the relay domain, not the recipient domain.

You may even be overriding the transport, and using other settings
in master.cf.  Hard to know, you don't provide enough information.

Is your Postfix compiled with TLS support?

> [root@smtp1 postfix]# cat /etc/postfix/tls_policy
> aexp.com secure match=wppim001.aexp.com:.wppim001.aexp.com

This suggests you're routing aexp.com traffic explicitly to
wppim0001.aexp.com, otherwise why hard-code that name in the match
clause?  What's wrong with:

# The default matching for "secure" is nexthop:dot-nexthop
# which should match the aexp MX host.
#
aexp.com secure

which should work provided you have no transport overrides, and your
Postfix is TLS-capable.

-- 
Viktor.

Re: How to relay specific domain over TLS and rest all other without TLS ?

2016-02-19 Thread Jayesh Shinde 



On 02/19/2016 05:01 AM, Viktor Dukhovni wrote:

On Thu, Feb 18, 2016 at 08:16:12PM +0530, Jayesh Shinde wrote:


How to relay only specific  domain's email on over TLS and rest all other on
port 25 as normal i.e without TLS ?

Postfix 2.3 .. 2.10:

 main.cf:
indexed = ${default_database_type}:${config_directory}/
smtp_tls_security_level = none
smtp_tls_policy_maps = ${indexed}tls-policy
smtp_tls_CAfile = ${config_directory}/CA_Bundle.pem

 tls-policy:
example.com secure match=nexthop:dot-nexthop

I am doing this setting for sending email to  "aexp.com" .
w.r.t  above info and docs i made below setting , but remote host saying 
" 530 Must issue a STARTTLS command first."

*
*http://www.postfix.org/postconf.5.html#smtp_tls_security_level
none :-- No TLS. TLS will not be used unless enabled for specific 
destinations via smtp_tls_policy_maps.


http://www.postfix.org/postconf.5.html#smtp_tls_policy_maps*


*current config for  postfix-2.10.0-1.el6.x86_64  main.cf :--

smtp_tls_security_level = none
smtp_tls_CAfile = /etc/postfix/CA_Bundle.pem
smtp_tls_policy_maps=hash:/etc/postfix/tls_policy

[root@smtp1 postfix]# cat /etc/postfix/tls_policy
aexp.com secure match=wppim001.aexp.com:.wppim001.aexp.com

Feb 19 13:50:43 smtp1 postfix/smtp[20613]: DE8E35FA0F: 
to=, relay=wppim001.aexp.com[148.173.96.171]:25, 
delay=7.8, delays=6.6/0/0.79/0.42, dsn=5.0.0, status=bounced (host 
wppim001.aexp.com[148.173.96.171] said: 530 Must issue a STARTTLS 
command first. (in reply to MAIL FROM command))


I am missing any config option ?

Regards
Jayesh Shinde