How to block sending outgoing mail from other domains in from field
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
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
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
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
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
On Tue, Jan 26, 2016 at 12:07 PM, btbwrote: > 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
> On Jan 26, 2016, at 15.52, Steve Jenkinswrote: > > 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
On Jan 26, 2016, at 09:22, Wietse Venemawrote: > transport_maps = inline:{u...@example.com=discard:} O, that is nifty! -- Suck it, Firefox!