Re: Query about restriction scenario in RESTRICTION_CLASS_README
Mayuresh: > On Wed, Jan 16, 2019 at 07:14:37AM -0500, Wietse Venema wrote: > > insiders_only = check_sender_access hash:/etc/postfix/insiders, > > reject > > On above line if I replace reject with reject_unauth_destination it > becomes permissive rather than rejecting. > > What is the exact difference between reject and reject_unauth_destination? reject, with error code: http://www.postfix.org/access.5.html (section: REJECT ACTIONS) reject_unauth_destination: http://www.postfix.org/postconf.5.html#reject_unauth_destination > I thought it's about rejecting with proper code. But looks like it has > different semantics. > > The problem with `reject' is the sender's server returns the mail calling > us as `improperly configured'. (Hope that doesn't lead to blacklisting!) I > think it's better to reject with proper error code. If you are unable to follow the example, then do not use it, or get professional advice (I am not available). Wietse
Re: Query about restriction scenario in RESTRICTION_CLASS_README
On Thu, Jan 17, 2019 at 07:25:42AM -0500, Wietse Venema wrote: > reject, with error code: > http://www.postfix.org/access.5.html (section: REJECT ACTIONS) > The default code of 5.7.1 is the one I want as well. Log and the bounced mail to gmail confirms that was the one that was used. But an additional remark gmail makes is "the remote server is misconfigured". Why would it call it misconfigured despite getting a legitimate code? Mayuresh
Re: Query about restriction scenario in RESTRICTION_CLASS_README
Mayuresh: > On Thu, Jan 17, 2019 at 07:25:42AM -0500, Wietse Venema wrote: > > reject, with error code: > > http://www.postfix.org/access.5.html (section: REJECT ACTIONS) > > > > The default code of 5.7.1 is the one I want as well. Log and the bounced > mail to gmail confirms that was the one that was used. > > But an additional remark gmail makes is "the remote server is > misconfigured". > > Why would it call it misconfigured despite getting a legitimate code? Because this is the Postfix mailing list, not gmail support. Wietse
Re: Query about restriction scenario in RESTRICTION_CLASS_README
On Thu, Jan 17, 2019 at 10:47:18AM -0500, Wietse Venema wrote: > > The default code of 5.7.1 is the one I want as well. Log and the bounced > > mail to gmail confirms that was the one that was used. > > > > But an additional remark gmail makes is "the remote server is > > misconfigured". > > > > Why would it call it misconfigured despite getting a legitimate code? > > Because this is the Postfix mailing list, not gmail support. Sorry. Read "other server" instead of gmail. The reason to ask this question on postfix list is to figure out whether my configuration* is flawed as some other servers report. [* as discussed on this thread before where sending email to protected ids is restricted to a list of senders. Others get a reject 554 5.7.1.] I agree I am not too knowledgable about mail servers and sorry if my very basic questions annoy you. But I am just trying to build the skill and in my experience of the world mailing lists are a great place to ask such queries. Usually. Mayuresh
Re: Query about restriction scenario in RESTRICTION_CLASS_README
On 17 Jan 2019, at 11:03, Mayuresh wrote: On Thu, Jan 17, 2019 at 10:47:18AM -0500, Wietse Venema wrote: The default code of 5.7.1 is the one I want as well. Log and the bounced mail to gmail confirms that was the one that was used. But an additional remark gmail makes is "the remote server is misconfigured". Why would it call it misconfigured despite getting a legitimate code? Because this is the Postfix mailing list, not gmail support. Sorry. Read "other server" instead of gmail. This is also not a mailing list for the support of unspecified "other servers." You truly need to ask whoever runs that other server to explain why they believe your server is misconfigured if you want a definitive answer.
Re: Question on how to deal with bad recipient address
Wietse, Thanks very much. That worked like a charm. cheers, ski On 1/16/19 4:09 PM, Wietse Venema wrote: > Ski Kacoroski: >> Hi, >> >> I have a blackbox UPS that send this email when I look at it with postcat >> >> *** MESSAGE CONTENTS deferred/B/BFE60169 *** >> regular_text: Received: from loki.nsd.org (ups-tms.nsd.org [10.145.1.25]) >> regular_text:by sys.nsd.org (Postfix) with ESMTP id BFE60169 >> regular_text:for ; Wed, 16 Jan 2019 >> 15:24:32 -0800 (PST) >> regular_text: Subject: TMS MDF ALARM USHA Test Message >> regular_text: From: >> regular_text: To: >> g.emergencypowerouta...@nsd.org >> >> Notice that there is no space between nsd,org and When I >> try to forward this email to O365, O365 scrambles the email into: >> >> nsd.orgg.emergencypowerouta...@nsd.org > > Now, that is not a robust parser... > >> and refuses to deliver it as that address doesn't exist. I tried a > > Office 365 uses the header to route the message? > >> regexp:/etc/postfix/virtual map: >> >> main.cf: >> virtual_alias_maps = regexp:/etc/postfix/virtual >> >> postmap -q >> "g.emergencypowerouta...@nsd.org" >> regexp:/etc/postfix/virtual >> g.emergencypowerouta...@nsd.org >> >> that adds in the space, but it does not seem to be working on the >> regular_text part of the email. > > Of course not. virtual_alias_maps rewrites the , not the > free text before . > > To fix non-address info in a header, use header_checks. > > Wietse > >> Any ideas on how I can get postfix to rewrite that part of the email so >> I can forward it on to O365. >> >> Thanks very much for your help. >> >> cheers, >> >> ski >> >> -- >> "When we try to pick out anything by itself, we find it >> connected to the entire universe"John Muir >> >> Chris "Ski" Kacoroski, kacoro...@gmail.com, 206-501-9803 >> -- "When we try to pick out anything by itself, we find it connected to the entire universe"John Muir Chris "Ski" Kacoroski, kacoro...@gmail.com, 206-501-9803
Re: TLS client certificates and auth external
Bastian Schmidt: > Shall I remove the check again? After all, it's just a simple if and > won't hurt. In case later someone makes initialization conditional it > would prevent the segfault. Removing this initialization would be a bad idea. The way the code works is that all table variables are initialized, so that the consumers of those tables do not have to worry about it. Wietse > > On 17.01.19 20:46, Wietse Venema wrote: > > Bastian Schmidt: > >> No, it would not segfault (permit_tls_clientcerts does not do any check > >> as well.). > > I see, because the relay_ccerts initialization is unconditional: > > > > relay_ccerts = maps_create(VAR_RELAY_CCERTS, var_smtpd_relay_ccerts, > >DICT_FLAG_LOCK | DICT_FLAG_FOLD_FIX); > > > > Therefore it is safe to acces the information. > > > >> However, I like the idea and added some checks to improve the patch. > > In this specific case there is no need to validate relay_ccerts. > > > > Wietse > > > >> Also, I was finally able to get dovecot installed for testing and have > >> fixed some issues for dovecot-sasl. > >> > >> Bastian > >> > >> > >> On 16.01.19 01:08, Wietse Venema wrote: > >>> Will this code segfault if relay_clientcerts is not specified? You > >>> may want to add some checks that information exists before using it. > >>> > >>> Wietse > >> > > [ Attachment, skipping... ] > > >
Re: Query about restriction scenario in RESTRICTION_CLASS_README
On Thu, Jan 17, 2019 at 11:22:46AM -0500, Bill Cole wrote: > You truly need to ask whoever runs that other server to explain why they > believe your server is misconfigured if you want a definitive answer. This is certainly strangest of the mailing lists I ever participated in. I am certainly signing off right away. All I wanted was some experience sharing with people who may have faced similar issues. Even a statement like there is no problem with your conf, the other servers are sometimes unreasonable could have helped. Sorry to have bothered you. Good luck. Mayuresh
