Am 16.09.2014 um 21:48 schrieb Philip Prindeville: > On Sep 14, 2014, at 2:17 AM, li...@rhsoft.net wrote: > >> Am 14.09.2014 um 01:54 schrieb Philip Prindeville: >>> On Sep 13, 2014, at 7:35 AM, li...@rhsoft.net wrote: >>>> Am 13.09.2014 um 15:10 schrieb LuKreme: >>>>> On 12 Sep 2014, at 13:55 , li...@rhsoft.net wrote: >>>>>> Am 12.09.2014 um 21:49 schrieb Philip Prindeville: >>>>>>>> However, any time I connect via telnet to this server and specify >>>>>>>> *any* IP address in the form [X.X.X.X], the smtpd_helo_restrictions >>>>>>>> won't trigger. >>>>>>> This is both legal and reasonable. >>>>>> >>>>>> it maybe true but it is *not* reasonable >>>>> >>>>> What do you base that on? >> >>> Who says anything about mail servers? >> >> the topic by definition > > > Really? I missed the part where the topic said "MTA-to-MTA exclusively"
logical conclusion because a MUA is using all sort of weird HELO names and typically falls into "permit_mynetworks" or "permit_sasl_authenticated" since it needs one of both to send mail outside the own domain without setup a open relay >>> What if it’s an MUA doing this? >> >> a MUA is using authentication and that is why you have >> *permit_sasl_authenticated* before such restrictions > > > It’s why you MIGHT have it. You’re not required to by any protocol standard > or universal policy. it's a common setup >> see the last paragraph of my post which refers to default settings >> and behavior of postfix, so the next time please hestitate to step >> into a topic saying something is completly reasonable by lack >> understand the topic > > Or perhaps you could be more specific and a little less arrogant. > > The default settings you mentioned were for the RECEIVING MTA. That receiving > MTA might be > speaking to either a SENDING MTA or a SUBMITTING MUA. i am not the OP the OP pretty clear talked about MTA to MTA by context i just refused "it is reasonable" in the context > And maybe you’re the one lacking understanding of the FULL SCOPE in which > these settings might be used. no - such settings are by definition for MTA-to-MTA because any of them would break most MUA in general >>>> you stripped that part from my quote >>>> because it is *easy* to do it right >>> >>> It’s EASIER to do if you know your topology. It’s impossible to do >>> with absolute certainty if you don’t >> >> if you don't know your topology don't setup a MTA > > Again, you’re confounding things. This is a setting on the RECEIVING MTA. and only a sending MTA completly weird configured is affected a MUA has different settings and should not use port 25 at all > A “EHLO” transaction is generated, by DEFINITION, from either a SENDING MTA > or a SUBMITTING MUA, which the RECEIVING MTA has no control over. yes, but that don't change the fact that MUA and MTA senders are handeled different >>>> if someone is not able to determine his public >>>> hostname and IP he better don't setup a MTA >>> >>> Again, it’s not just MTA’s which speak SMTP… >> >> again - only MTA's have to deliver unauthenticated mail > > But they have to communicate with both sending MTA’s and submitting MUA’s not in the context > You don’t know if you’re in the delivery step until AFTER you’ve seen the > EHLO, AFTER you’ve seen the MAIL > FROM, AFTER you’ve seen the RCPT TO, and AFTER you’ve seen the DOT (since > their might be restrictions on > content type, content length, etc). that's why postfix makes the decision AFTER all of that > So whether it’s ultimately a delivery transaction or not is not determined at > the moment an MTA has seen an EHLO… no >>>> the same way as your internel PTR and A record don't count in >>>> the internet your internal hostname also is not relevant - set >>>> the HELO name to the public one matching the public DNS redcords >>>> and if you don't know where to do so don't setup a public mail server >>> >>> What if you’re on an ISP (like Comcast residential) which won’t give you a >>> fixed address? >> >> than you don't have to run a MTA, hence that rules >> if you runa MTA there then you have to use a smarthost for delivery > > AGAIN, the controls you’re talking about are about the RECEIVING MTA getting > a specific type of EHLO which is generated BY THE REMOTE SIDE. AGAIN a MUA is handeled different to a MTA > This has nothing to do with the configuration of the receiving MTA and > everything to do with the REMOTE PEER. > Which part of this should I draw a picture for? no need >> if you are a legit MUA you have to use SMTP auth and so the >> rule sdon't affect you > > You’re confusing both sending and receiving roles, and failing to > differentiate > per-site policy from protocol (which is universal). i confuse nothing, i have both in mind and which rules can be applied and how >>>>> What problem are you having that you are trying to solve? >>>> >>>> have you ever seen a non-spam connection on a inbound MX with >>>> such a HELO - yes it happens 1 out of 100000 and only because >>>> people continue to tell it is reasonable instead block such >>>> connections >>> >>> Yeah, all the time. Each of the company employees when >>> he’s out-of-office and connecting remotely. >> >> that is pure bullshit in that case they are using SMTP >> authentication and so they are not affected by MTA rules >> or otherwise fire your mailadmin >> >> please come back after read some prerequisite for a topic like this > > I’ve been doing this a long time… I’ve contributed to Thunderbird, Fedora, > Sendmail, Postfix, MMDF, Qmailer, Cyrus, MAIL-11, Zmail… and a couple of the > MIME and Mail RFC’s. congratulations > I’ve also had to see a great many corner cases. me too >>> You’re forgetting that UNTIL you’ve seen the MAIL FROM and RCPT TO, >>> you don’t know if this is a CLIENT submitting the message to the >>> OUTBOUND MTA, or another MTA attempting FINAL DELIVERY. >> >> bullshit - the MUA is using authentication > > > Not necessarily. > > You might be using their IP address and doing lookups > in MIMEDefang (if the MUA’s are at fixed remote locations). > They might be using dyndns and you’re trusting them based > on the rDNS lookup of their IP to match your domain. thats why you put permit_mynetworks, permit_sasl_authenticated, check_helo_access or whatever you need in front of such rules > You might be using VPN and blocking/permitting based on network numbers. permit_mynetworks in front of > You’re making WAY too many assumptions. no, my sample was from a inbound-only MTA no user ever has to submit there a message and as said above if you need to have both roles on one machine there are rules to put before the HELO restricitions > I’m not saying these are scenarios I’d endorse. But they most certainly are > real-world cases. you forget the whole time the complete setup which includes rules before the recjet rules - you need them anyways on some place to allow realy without become a open realy > A good design goal of a software architect is to help devise a ladder so that > people who > have dug themselves into holes can eventually get themselves back out again. > > You’re overly restrictive assumptions would effectively nail a lid on that > hole. Not good. > Certainly not helpful. for a inbound message where all rules before saing "that is not one of my legit users" - surely >>> So you can’t block on the HELO because that’s way too early >> >> bullshit - http://www.postfix.org/postconf.5.html#smtpd_delay_reject >> >> smtpd_delay_reject (default: yes) >> Wait until the RCPT TO command before evaluating $smtpd_client_restrictions, >> $smtpd_helo_restrictions and $smtpd_sender_restrictions, or wait until the >> ETRN command before evaluating $smtpd_client_restrictions >> and $smtpd_helo_restrictions >> >> smtpd_helo_restrictions = >> check_helo_access proxy:regexp:/etc/postfix/blacklist_helo.cf >> check_sender_access proxy:hash:/etc/postfix/whitelist_sender.cf >> reject_non_fqdn_helo_hostname >> reject_invalid_helo_hostname > > > That really doesn’t change anything: a bracketed dotted-quad is still a valid > argument > for HELO/EHLO, and it can’t be rejected as an non-fdqn hostname or an invalid > hostname > because (as has been pointed out) it’s NOT A HOSTNAME. that is true but don't make it *reasonable* to use it for MTA-to-MTA that was the only thing i rejected in your answer > If you wanted an additional check, called reject_dotted_quad_helo then you > should > come up with a patch for this. no need "check_helo_access" exists you forget i am not the OP i just rejected your "it is reasonable" > Don’t try to pervert a correctly implemented mechanism for your own specific > means. > Again, separate policy from protocol, as Postel used to drum into my head. > It was good advice. i even seperate inbound mail and outbound mail on different machines
