Re: Sending notification to sender
El 21/03/2014 20:08, Robert Schetterer escribió: Am 21.03.2014 18:47, schrieb Ignacio Garcia: Hi there and thanks in advance for your help. I wish I could send an automated notification upon receiving emails from a couple of domains. for example, let's assume those domains are hotmail.com and gmail.com. What I need is, everytime my users receive a message from either any...@hotmail.com or any...@gmail.com an automated message is sent to those accounts. Is there anyway I can implement that? Thanks in advance Ignacio do you mean something like vacation mail script or equal ? you might try solve this with sieve , procmail or maildrop etc, but be aware how you configure it, you may get blacklisted anytime anywhere for mail flooding etc, your question sounds not like its a job for postfix itself i.e perhaps look Sieve Notification Mechanism: mailto http://tools.ietf.org/html/rfc5436 specially read Security Considerations also look on other sieve filters Best Regards MfG Robert Schetterer Great. That is what I was looking for. Thanks so much. Ignacio
Re: Reject client from domains without MX records
Thank you everyone. Your advises has been very useful to resolve this issue. On Sat, Mar 22, 2014 at 2:17 PM, Wietse Venema wie...@porcupine.org wrote: Pau Peris: Thanks for the explanation but i think i'm not understanding you. I understand MX records are not mandatory but i'm wondering what am i supposed to do when someone tries to send an email and the from address is not valid but an A or CNAME RR exists? This is described in RFC 5321 section 5.1. Wietse
Re: Reject client from domains without MX records
I'm wondering why are you setting the following policies under recipient restrictions and not under sender restrictions? Maybe it's more efficient? reject_non_fqdn_sender reject_unlisted_sender reject_authenticated_sender_login_mismatch Last, what do you think about reject_unverified_sender? Is it a resources drainer? Thanks a lot! On Mon, Mar 24, 2014 at 8:44 PM, Pau Peris p...@webeloping.es wrote: Thank you everyone. Your advises has been very useful to resolve this issue. On Sat, Mar 22, 2014 at 2:17 PM, Wietse Venema wie...@porcupine.orgwrote: Pau Peris: Thanks for the explanation but i think i'm not understanding you. I understand MX records are not mandatory but i'm wondering what am i supposed to do when someone tries to send an email and the from address is not valid but an A or CNAME RR exists? This is described in RFC 5321 section 5.1. Wietse
Re: Reject client from domains without MX records
Am 24.03.2014 20:54, schrieb Pau Peris: I'm wondering why are you setting the following policies under recipient restrictions and not under sender restrictions? Maybe it's more efficient? reject_non_fqdn_sender reject_unlisted_sender reject_authenticated_sender_login_mismatch because with smtpd_delay_reject which is default for good reasons it does not matter and the configuration is easier to understand as well as specific overrides are better to manage reject_non_fqdn_sender reject_unlisted_sender reject_authenticated_sender_login_mismatch Last, what do you think about reject_unverified_sender? Is it a resources drainer? it may lead to blacklisting because you always make a sending attempt and in case of forged senders you do that to servers never tried to send a message to you
Using master.cf to modify main.cf options
We use Mandrill (a MailChimp offering) for the Admissions Office bulk emailing to perspective students. We have now set up a second Mandrill account that has to authenticate with a different username/password (or key as Mandrill calls it). The key is mapped to this hash below. smtp_sasl_password_maps=hash:/etc/postfix/sasl_passwd For the second account, I have created a second password file, sasl_passwd_campus and I’ve configured master.cf as follows: smtp inet n - n - - smtpd 2025 inet n - n - - smtpd -o smtp_sasl_password_maps=hash:/etc/postfix/sasl_passwd_campus My expectation is that when I connect to Postfix on port 2025, the one map will override the other, but it doesn’t appear to be doing do. All the messages being delivered to Mandrill are coming in on the Admissions account and not the new second account. What am I doing wrong here? Thanks, Rob Tanner UNIX Services Manager Linfield College, McMinnville Oregon ITS will never ask you for your password. Please don’t share yours with anyone!
Re: Using master.cf to modify main.cf options
On Mon, Mar 24, 2014 at 10:48:43PM +, Rob Tanner wrote: For the second account, I have created a second password file, sasl_passwd_campus and I've configured master.cf as follows: smtp inet n - n - - smtpd 2025 inet n - n - - smtpd -o smtp_sasl_password_maps=hash:/etc/postfix/sasl_passwd_campus This makes no sense, the setting is Postfix SMTP *client* setting, but you're applying to a Postfix SMTP *server* instance. My expectation is that when I connect to Postfix on port 2025, the one map will override the other, but it doesn't appear to be doing it. The SMTP server makes no use of this parameter. What real problem are you trying to solve? In other words, what do you want to do differently with email that you were planning to receive on port 2025. All the messages being delivered to Mandrill are coming in on the Admissions account and not the new second account. What am I doing wrong here? Mostly not yet asking the right question. Ask for help with your real problem (describe it in detail) not the tentative solution that is not working, and may not be the right approach. -- Viktor.
Re: Reject client from domains without MX records
Hundred thanks!! Really great help, tomorrow gonna put it all together and solve the issue. Good night! On Mon, Mar 24, 2014 at 9:06 PM, li...@rhsoft.net li...@rhsoft.net wrote: Am 24.03.2014 20:54, schrieb Pau Peris: I'm wondering why are you setting the following policies under recipient restrictions and not under sender restrictions? Maybe it's more efficient? reject_non_fqdn_sender reject_unlisted_sender reject_authenticated_sender_login_mismatch because with smtpd_delay_reject which is default for good reasons it does not matter and the configuration is easier to understand as well as specific overrides are better to manage reject_non_fqdn_sender reject_unlisted_sender reject_authenticated_sender_login_mismatch Last, what do you think about reject_unverified_sender? Is it a resources drainer? it may lead to blacklisting because you always make a sending attempt and in case of forged senders you do that to servers never tried to send a message to you -- *Pau Peris Rodriguez* *Chief Executive Officer (CEO)* Tel: 669650292 C/Balmes 211, Principal Segunda Barcelona 08006 http://www.webeloping.es Aquest correu electrònic conté informació de caràcter confidencial dirigida exclusivament al seu/s destinatari/s en còpia present. Tant mateix, queda prohibida la seva divulgació, copia o distribució a tercers sense prèvia autorització escrita per part de Pau Peris Rodriguez. En cas d'haver rebut aquesta informació per error, es demana que es notifiqui immediatament d'aquesta circumstancia mitjançant la direcció electrònica del emissor.
