Hello,
lets say a client connects and triggers several errors. For instance: EHLO asdf .... mail from: [hidden email] 250 2.1.0 Ok rcpt to: [hidden email] 504 5.5.2 <asdf>: Helo command rejected: need fully-qualified hostname why did the "Helo command rejected" come not immediately after the wrong EHLO ? Why did postfix wait until failed relay, to report ehlo? And even worse, the client tries to relay mail, but no "relay access denied" is being logged. I am much more interested in "relay access denied", than non-FQDN ehlo. Does postfix have some priorities which errors it logs preferentially? thanks, |
On 14.01.21 11:27, Fourhundred Thecat wrote:
>lets say a client connects and triggers several errors. For instance: > > EHLO asdf > .... > mail from: [hidden email] > 250 2.1.0 Ok > rcpt to: [hidden email] > 504 5.5.2 <asdf>: Helo command rejected: need fully-qualified hostname > >why did the "Helo command rejected" come not immediately after the wrong >EHLO ? Why did postfix wait until failed relay, to report ehlo? to log all parameters, like mail from: and rcpt to: Helps much when digging logs why was someone's mail refused. >And even worse, the client tries to relay mail, but no "relay access >denied" is being logged. the mail can only be rejected with one error. The first error is used. >I am much more interested in "relay access denied", than non-FQDN ehlo. you can disable the helo checks. I don't recommend that. I usually allow both relaying and simple helo strings for authenticated mail. -- Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. It's now safe to throw off your computer. |
On 14 Jan 2021, at 7:53, Matus UHLAR - fantomas wrote:
> On 14.01.21 11:27, Fourhundred Thecat wrote: >> lets say a client connects and triggers several errors. For instance: >> >> EHLO asdf >> .... >> mail from: [hidden email] >> 250 2.1.0 Ok >> rcpt to: [hidden email] >> 504 5.5.2 <asdf>: Helo command rejected: need fully-qualified >> hostname >> >> why did the "Helo command rejected" come not immediately after the >> wrong >> EHLO ? Why did postfix wait until failed relay, to report ehlo? > > to log all parameters, like mail from: and rcpt to: > Helps much when digging logs why was someone's mail refused. Also, technically, because smtpd_delay_reject is "yes" which is the default in recent versions of Postfix. The rationale for smtpd_delay_reject is both to allow for logging of sender and recipient(s) and to reject mail at a point (RCPT) where all generally well-behaved senders will recognize it as an unconditional permanent failure. Historically some MTAs responded to 5xx replies before RCPT by retrying, which isn't what you want. >> And even worse, the client tries to relay mail, but no "relay access >> denied" is being logged. > > the mail can only be rejected with one error. The first error is used. > >> I am much more interested in "relay access denied", than non-FQDN >> ehlo. > > you can disable the helo checks. I don't recommend that. Rather than disabling helo checks, it is possible to put them in smtpd_recipient_restrictions or smtpd_relay_restrictions *AFTER* actual relay restrictions, so that the first error hit is the unauthorized relay. Note that because helo checks are usually extremely fast (e.g. checking a string for a '.') it may be better on extremely performance-sensitive systems to keep helo checks in smtpd_helo_restrictions so that those cheap rejections are done without going through the slower work that may be required for nuanced relay restrictions, such as full-circle DNS lookups. > I usually allow both relaying and simple helo strings for > authenticated > mail. Authentication is best reserved for submission services (ports 465 and 587,) not inbound (port 25) SMTP. -- Bill Cole [hidden email] or [hidden email] (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire |
On Thu, Jan 14, 2021 at 10:14:49AM -0500, Bill Cole wrote:
> > to log all parameters, like mail from: and rcpt to: > > Helps much when digging logs why was someone's mail refused. > > Also, technically, because smtpd_delay_reject is "yes" which is the > default in recent versions of Postfix. Not just "recent", every stable release (starting with 1.0): https://github.com/vdukhovni/postfix/blame/master/postfix/src/global/mail_params.h#L2406-L2408 on by default since 19990510. > > you can disable the helo checks. I don't recommend that. > > Rather than disabling helo checks, it is possible to put them in > smtpd_recipient_restrictions or smtpd_relay_restrictions *AFTER* actual > relay restrictions, so that the first error hit is the unauthorized > relay. Unfortunately, smtpd_recipient_restrictions runs *before* smtpd_relay_restrictions (in recent Postfix releases), and there was some discussion of making that configurable, but I forget where that ended up... I agree that one would naively expect the relay checks to run first, and the current behaviour (though "safer" in some sense) is surprising. -- Viktor. |
Viktor Dukhovni:
> > Rather than disabling helo checks, it is possible to put them in > > smtpd_recipient_restrictions or smtpd_relay_restrictions *AFTER* actual > > relay restrictions, so that the first error hit is the unauthorized > > relay. > > Unfortunately, smtpd_recipient_restrictions runs *before* > smtpd_relay_restrictions (in recent Postfix releases), and there was > some discussion of making that configurable, but I forget where that > ended up... I agree that one would naively expect the relay checks > to run first, and the current behaviour (though "safer" in some > sense) is surprising. We could gate this with "compatibility_level = 3.6" which is already being used for some TLS-related breaking changes. Strawman: smtpd_relay_before_recipient_restictions = ${ {$compatibility_level} <level {3.6} ? {no} : {yes} } The weird '<level' operator is needed because we're switching compatibility_level settings from 1, 2, ... to settings that match the Postfix version that introduces the breaking change. With the old '<' operator, 3.10 would be smaller than 3.9 which is undesirable. Wietse |
On Thu, Jan 14, 2021 at 11:40:34AM -0500, Wietse Venema wrote:
> > Unfortunately, smtpd_recipient_restrictions runs *before* > > smtpd_relay_restrictions (in recent Postfix releases), and there was > > some discussion of making that configurable, but I forget where that > > ended up... I agree that one would naively expect the relay checks > > to run first, and the current behaviour (though "safer" in some > > sense) is surprising. > > We could gate this with "compatibility_level = 3.6" which is already > being used for some TLS-related breaking changes. > > Strawman: > > smtpd_relay_before_recipient_restictions = > ${ {$compatibility_level} <level {3.6} ? {no} : {yes} } Yes, that seems quite reasonable. Note to the reader, there is no typo there, the correct syntax is as written above with "{$compatibility_level}" and not what you'd typically see in shell scripts, etc. "${compatibility_level}". The reason is that per postconf(5): http://www.postfix.org/postconf.5.html The expression "${name?{value1}:{value2}}" is replaced with "value1" when "$name" is non-empty, and with "value2" when "$name" is empty. The "{}" is required for "value1", optional for "value2". The parameter name must contain only characters from the set [a-zA-Z0-9_]. This form is supported with Postfix versions >= 3.0. The first item inside "${...}" may be a relational expression of the form: "{value3} == {value4}". Besides the "==" (equality) operator Postfix supports "!=" (inequality), "<", "<=", ">=", and ">". The comparison is numerical when both operands are all digits, otherwise the comparison is lexicographical. These forms are supported with Postfix versions >= 3.0. [ The HTML manpage displays unicode glyphs for "<=" and ">=", but these are not supported in that form. ] -- Viktor. |
Free forum by Nabble | Edit this page |