How to block sending outgoing mail from other domains in from field

2016-01-26 Thread Amit Bondwal
Hi Everyone,

In my postfix mail server, users are able to send mail on name of different
domains
using from field in mail client software.

For eg. I am using sendEmail mail client, and I can send emails with
hdfc.com domain or other too,

sendEmail -v -f "a...@hdfc.com" -s "test.example.in:25" -xu "amit" -xp
"ami*321" -t "x...@yahoo.co.in"  -u "test from sendEmaili 0255" -m "this is
sendEmail test"

This mail goes to spam and it did not show actual mail address in details
header.

How Can I restrict my outgoing mails such that it can only send outgoing
mails which have my domain  test.example.in? or it would be great if I can
map user's too that user can't use other users name.

If only first case work that will be sufficient for me.

I searched a lot but not able to do this. my postfix version is 2.11.3-1 on
debian Jessie. My setup have just postfix with sasl authentication,
authentication is working fine.


--
Thanks

Amit Bondwal


Adding a noreply address

2016-01-26 Thread Matt Bayliss
I'm trying to find the correct/best practice method for setting up a black
hole email address for such items as "noreply" addresses when sending
alerts from monitoring devices etc.

I have come across a couple of tutorials which has instructions such as:



" edit the /etc/postfix/aliases file and add there as bottom line:

devnull: /dev/null

- rebuild the aliases.db file with the command:

newaliases

- edit the /etc/postfix/virtual file and add as bottom line (replace the
example.com domain with your main virtual domain):

blackh...@example.com devnull

- rebuild virtual.db file with the command:

postmap /etc/postfix/virtual



Now create a mail user or alias that is forwarded to
blackh...@example.com ... that's all!"


So I don't really want to create a user on the system unless its really
necessary so how would I alias it, is that not already done when editing
/etc/postfix/aliases.p, all I really want is a specific address in the mail
domain to silently accept and drop any mail sent to it.

Error in log isRecipient address rejected: User unknown in local
recipient table; from=<> to=nore...@domain.com

Thanks,


Re: Adding a noreply address

2016-01-26 Thread Ralph Seichter
On 26.01.2016 16:54, Matt Bayliss wrote:

> I'm trying to find the correct/best practice method for setting up a
> black hole email address for such items as "noreply" addresses when
> sending alerts from monitoring devices etc.

While not necessarily "the best" solution, I use this:

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

You'll need to make sure that this file is used of course, like so:

  # /etc/postfix/main.cf
  smtpd_recipient_restrictions =
   permit_mynetworks
   permit_sasl_authenticated
   check_recipient_access pcre:${config_directory}/recipient_access
   reject_non_fqdn_recipient
   reject_unlisted_recipient
   reject_unknown_recipient_domain

I include many other entries in recipient_access and it makes sense for
me to ignore the access file for mynetworks or sasl_authenticatd clients.
Change this if necessary.

-Ralph


Re: Adding a noreply address

2016-01-26 Thread Wietse Venema
Matt Bayliss:
> I'm trying to find the correct/best practice method for setting up a black
> hole email address for such items as "noreply" addresses when sending
> alerts from monitoring devices etc.

With Postfix 3.0 and later:

/etc/postfix/main.cf:
transport_maps = inline:{u...@example.com=discard:}

This requires "postfix reload".

With Postfix 2.2 and later:

/etc/postfix/main.cf:
transport_maps = hash:/etc/postfix/transport

/etc/postfix/transport:
 u...@example.com   discard:

This requires "postmap hash:/etc/postfix/transport" and "postfix reload".

Wietse


Re: Adding a noreply address

2016-01-26 Thread btb

On 2016.01.26 10.54, Matt Bayliss wrote:

I'm trying to find the correct/best practice method for setting up a
black hole email address for such items as "noreply" addresses when
sending alerts from monitoring devices etc.


if you intend no mail to be sent to this address anyway, and will just 
throw away any mail that arrives, then why bother accepting mail for the 
address at all?  pick an address you like, configure your various 
devices to use it when sending mail, and don't worry about postfix.  if 
someone tries to send mail to that address, postfix will reject it.


-ben



Re: Adding a noreply address

2016-01-26 Thread Steve Jenkins
On Tue, Jan 26, 2016 at 12:07 PM, btb  wrote:

> On 2016.01.26 10.54, Matt Bayliss wrote:
>
>> I'm trying to find the correct/best practice method for setting up a
>> black hole email address for such items as "noreply" addresses when
>> sending alerts from monitoring devices etc.
>>
>
> if you intend no mail to be sent to this address anyway, and will just
> throw away any mail that arrives, then why bother accepting mail for the
> address at all?  pick an address you like, configure your various devices
> to use it when sending mail, and don't worry about postfix.  if someone
> tries to send mail to that address, postfix will reject it.


Yep. It all boils down to what you want to occur if someone replies to the
"noreply" address.

1) Want the reply to disappear and not bounce back to the sender? Point the
noreply alias to /dev/null (that's different than setting up a "noreply"
user -- an alias is not a user account).

2) Want the reply to bounce back to the sender? Make sure you don't have a
noreply alias or catchall, and Postfix will send the appropriate "no such
recipient" error to the sender.

3) Want to send a custom "Sorry, we don't check this email account so
please don't expect a reply" message to the sender? Set up an auto-reply
(and send the incoming message at /dev/null), but do so prudently so as to
avoid any backscatter concerns (seriously... backscatter and auto-reply
wars are no bueno).

Option has the most potential pitfalls, so I'm a fan of Options 1 and 2.
Both are completely acceptable as "best practices" for "black hole" email
addresses for alerts from monitoring devices.

A fourth option (which I do for certain alerts such as smart UPS battemy
systems) might also be having the messages come from root, so that if
deliverability TO the desired alert addresses fails, the bounce has
somewhere to go that you might eventually see (I quickly browse through and
delete messages to root on my servers once every 2-3 days).

SteveJ


Re: Adding a noreply address

2016-01-26 Thread btb

> On Jan 26, 2016, at 15.52, Steve Jenkins  wrote:
> 
> On Tue, Jan 26, 2016 at 12:07 PM, btb  wrote:
> On 2016.01.26 10.54, Matt Bayliss wrote:
> I'm trying to find the correct/best practice method for setting up a
> black hole email address for such items as "noreply" addresses when
> sending alerts from monitoring devices etc.
> 
> if you intend no mail to be sent to this address anyway, and will just throw 
> away any mail that arrives, then why bother accepting mail for the address at 
> all?  pick an address you like, configure your various devices to use it when 
> sending mail, and don't worry about postfix.  if someone tries to send mail 
> to that address, postfix will reject it.
> 
> Yep. It all boils down to what you want to occur if someone replies to the 
> "noreply" address.
> 
> 1) Want the reply to disappear and not bounce back to the sender? Point the 
> noreply alias to /dev/null (that's different than setting up a "noreply" user 
> -- an alias is not a user account).
> 
> 2) Want the reply to bounce back to the sender? Make sure you don't have a 
> noreply alias or catchall, and Postfix will send the appropriate "no such 
> recipient" error to the sender.
> 
> 3) Want to send a custom "Sorry, we don't check this email account so please 
> don't expect a reply" message to the sender? Set up an auto-reply (and send 
> the incoming message at /dev/null), but do so prudently so as to avoid any 
> backscatter concerns (seriously... backscatter and auto-reply wars are no 
> bueno).
> 
> Option has the most potential pitfalls, so I'm a fan of Options 1 and 2. Both 
> are completely acceptable as "best practices" for "black hole" email 
> addresses for alerts from monitoring devices.

fwiw, i would never consider accepting mail and then discarding it "best 
practices" [which is a term i'm not fond of anyway] - especially if you knew 
full well that was your intent before the message even arrived.  very much 
agreed on the backscatter/autoresponder caution though.

-ben

Re: Adding a noreply address

2016-01-26 Thread LuKreme
On Jan 26, 2016, at 09:22, Wietse Venema  wrote:
> transport_maps = inline:{u...@example.com=discard:}

O, that is nifty!

-- 
Suck it, Firefox!