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”… > >> 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. > > 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. And maybe you’re the one lacking understanding of the FULL SCOPE in which these settings might be used. > >>> 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. A “EHLO” transaction is generated, by DEFINITION, from either a SENDING MTA or a SUBMITTING MUA, which the RECEIVING MTA has no control over. > >>> 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. 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). So whether it’s ultimately a delivery transaction or not is not determined at the moment an MTA has seen an EHLO… > >>> 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. 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? > > 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). > >>>> 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. I’ve also had to see a great many corner cases. > >> 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. You might be using VPN and blocking/permitting based on network numbers. You’re making WAY too many assumptions. I’m not saying these are scenarios I’d endorse. But they most certainly are real-world cases. 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. > >> 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. If you wanted an additional check, called reject_dotted_quad_helo then you should come up with a patch for this. 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. -Philip
