Address rewriting v Virtual alias domains
Hello all,
I would like to implement rewriting of envelope recipient addresses
as they are recieved by smtpd(8) prior to the respective message being
fed into "the queue", based solely on the form of the envelope recipient
addresses in question. So far, I was able to figure out that to accomplish
this task for arbitrary address/domains, the virtual(5) tables are the
means to express these relationships, and that the cleanup(8) daemon
does the actual work.
Specifically, I would like to make sure that the case-insensitive
forward-path as required by RFC 5321 [1] is rewritten
to , where
mydestination = $myhostname
holds.
Secondly, I would like to have either forward-path
and each of the(no $proxy_interfaces here)
rewritten to the forward-path .
Assuming that I maintain neither local domains nor relay domains, and only
virtual mailbox domains, and that
myorigin = $myhostname
holds, the first requirement might be accomplished with having
append_at_myorigin = yes
local_recipient_maps = inline:{ { postmaster = - } }
although I am uncertain about whether the maps specified
for local_recipient_maps perform case-folding like virtual(5)
maps do. The LOCAL_RECIPIENT_README did not help in this regard,
either.
To satisfy the second requirement, I currently have
virtual_alias_domains =
virtual_alias_maps=
inline:{ { postmaster = postmaster@⟨some virtual mailbox domain⟩ } }
and this is where the problem starts.
The manpage to virtual(5) suggests in section TABLE SEARCH ORDER that
it first tries left hand sides of the form ⟨local-part⟩@⟨domain⟩ ,
then ⟨local-part⟩ and finally @⟨domain⟩ . It also introduces the
concept of virtual alias domains and that with an empty
virtual_alias_domains , the /first line/ of (any of) the maps
in virtual_alias_maps tell cleanup(8) what that virtual alias domain
is. However, since only the left hand side of that first line is being
evaluated to decide what that virtual alias domain is, an ambiguity is
introduced w.r.t. non-virtual alias domain rewriting. This is because,
syntactically, a ⟨local-part⟩ like postmaster is indistinguishable
from a ⟨domain⟩ [2], more so firstname.lastname (notice the dot).
So, the question is, how do I tell Postfix to disable its virtual alias
domain machinery, yet have the full power of address rewriting with
virtual(5) at my disposal?
Thanks,
Mono
[1] https://datatracker.ietf.org/doc/html/rfc5321#section-4.1.1.3 RECIPIENT
(RCPT)]
[2] https://datatracker.ietf.org/doc/html/rfc5321#section-4.1.2 Command
Argument Syntax
signature.asc
Description: PGP signature
EHLO argument validation
Hello all, RFC 5321, in section 4.1.1.1, states that a valid argument to the EHLO command is either a ⟨Domain⟩ or an ⟨address-literal⟩. Postfix allows the adminstrator to selectively control access to the SMTP server either by ⟨Domain⟩ via the check_helo_access , the check_helo_mx_access or check_helo_ns_access tables, or by the IP addresses resolved from that ⟨Domain⟩ via check_helo_a_access tables. Since ⟨address-literal⟩s are legal arguments for the EHLO command, which of the check_helo_access or check_helo_a_access tables are appropriate to control access to the SMTP server based on ⟨address-literal⟩s, as opposed to the IP addresses resolved from ⟨Domain⟩s? Thanks, Mono signature.asc Description: PGP signature
Re: EHLO argument validation
Hello, On 2021-08-08, at 16:13 (UTC+0200), Matus UHLAR - fantomas had the following to say: : are you searching for disabling particular strings in helo/ehlo command? No, I would like to validate the argument to the EHLO command (actually, to both the EHLO and HELO commands, but see below). The standard says that it must have the form of a ⟨Domain⟩ or ⟨address-literal⟩ (only ⟨Domain⟩s allowed with HELO), and be a "primary host name" [1] for the former. A primary host name is defined as an FQDN that resolves to an A or RRset, as opposed to merely an MX RRset. However, there are globally well-defined domain names [2], as well as IP addresses [3], that satisfy these respective productions, yet have special semantics that preclude them from appearing in any /meaningful/ SMTP conversation on the public Internet -- either as argument to the EHLO/HELO command or the ⟨Domain⟩ part in a ⟨Mailbox⟩, where only ⟨Domain⟩s are allowed. It's only logical, then, to weed them out before we even invoke the DNS lookup machinery in our attempts to resolve a domain name that -- by definition -- is to produce an NXDOMAIN from any well-administered public DNS server, anyway. I currently only have the domain names listed in a check_helo_access table with a REJECT action for each and all its sub-domains, and would like to extend this functionality to ⟨address-literal⟩s for the EHLO command case. The way I understand the workings of the check_helo_access tables is that no DNS lookup is performed before the table is consulted. So far, so good. The check_helo_a_access tables are only consulted with the /result/ of a DNS lookup, and are therefore not suitable, since we do not need to look up an ⟨address-literal⟩ EHLO argument. My current approach consists of either having both domain names and IP addresses in one check_helo_access table (operationally preferred, but insufficient for specifying all IP address forms) or use /two/ check_helo_access tables in succession: one access(5) table for domain names followed by one cidr_table(5) for IP addresses. The latter is a consequence of the fact that these special addresses are all defined as CIDR blocks, and some of them with prefixes that aren't integer-multiples of 8, which rules out access(5) tables for those IP addresses. Another complication arises with SMTP clients that only introduce themselves with the HELO command. In that particular case, as near-pathological as it may seem these days, I would /only/ like the domain name table to be consulted, and not the IP address table, since, well, ⟨address-literal⟩s aren't allowed as arguments to the HELO command. Any comments, suggestions? Thanks, Mono [1] https://datatracker.ietf.org/doc/html/rfc5321#section-2.3.5 [2] https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml [3] https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml signature.asc Description: PGP signature
Re: EHLO argument validation
Hello, On 2021-08-08, at 10:25 (UTC-0400), Wietse Venema had the following to say: : Mono DHS: : : Checking application/pgp-signature: FAILURE Perhaps hkps://keyserver.ubuntu.com might help. Key servers are the bane of OpenPGP. I don't own/control the domain of the email address I am writing under, so there is no way for me to have DANE records of my public keys in the DNS. : There is a comment in the function that implements check_xxx_yy_access: : : /* : * Treat an address literal as its own MX server, just like we treat a : * name without MX record as its own MX server. There is, however, no : * applicable NS server equivalent. : */ Basically, all I want is to avoid DNS lookups where they contribute no new information. And we certainly do not need those for ⟨address-literal⟩s. It would appear that check_helo_a_access tables provide indeed what I need. Its documentation somewhat strays from what the code actually makes the reader believe, because the former does only mention "IP addresses for the HELO or EHLO hostname", and not its capability to deal with ⟨address-literal⟩s. That's an important operational distinction to make. There is another comment in check_server_access() a little further down, that reads /* * If the request is type A or , fabricate an MX record that points * to the domain name itself, and skip name-based access control. … What is "name-based access control", and how does it differ from what check_domain_access() does? Thanks, Mono signature.asc Description: PGP signature
Re: ALPACA writeup
Hello, On 2021-08-03, at 14:11 (UTC-0400), Wietse Venema had the following to say: : > Just wondering, did you add the anti-http stuff because of ALPACA or was it already there? : > : : Postfix 2.2 added both the GET etc. configurable forbidden word : list and header detection (changelog says 20041124). Out of utter bewilderment and honest curiosity, I'd be interested to know how and why /non/-SMTP commands would be considered for the implementation of an SMTP MTA in the first place. Haven't seen anything even remotely concerning HTTP in any SMTP standard. Thanks, Mono signature.asc Description: PGP signature
Re: ALPACA writeup
Hello, On 2021-08-09, at 09:39 (UTC-0400), Wietse Venema had the following to say: : > Haven't seen anything even remotely concerning HTTP in any SMTP standard. : : You assume that clients will adhere to the SMTP standard. Oh, no, I assume that we speak SMTP when it is agreed upon to do so, and nothing else, with emphasis on the latter. Consequently, anything that does not look like SMTP is rejected. The Internet has a nice way of signaling "only SMTP spoken here" by offering SMTP MTA services on TCP port 25 and 587/465 for SMTP Submission. The general public already conflating the Web with the Internet is bad enough, at least systems people should be able to keep separate things separate, simple and robust. Thanks, Mono signature.asc Description: PGP signature
Re: ALPACA writeup
Hello again, On 2021-08-09, at 09:39 (UTC-0400), Wietse Venema had the following to say: : There was a Postfix-users thread that led to this. : https://marc.info/?t=11012289581&r=1&w=2 Uh, oh. The example conversation is noteworthy for two reasons. First, upon receiving input consisting of the three tokens "POST", "/", and "HTTP/1.0", the server should have recognised that such a token sequence does not constitute a valid SMTP command line. Second, when replying with code 502, the server suggests that in fact there exists in the standard SMTP protocol definition or the local interpretation of it an action named "POST", and the server recognised it as such, but it is not (yet) implemented. This differs semantically from "I do not recognise this token sequence as a command line at all". The semantics for 502 are made very clear in RFC 5321 [1,2], where 504 (command implemented, but one of its parameters isn't) for example, is considered a refinement of 502. The server hanging on to a connection is the expected behaviour when replying with 502, because in such a case, there was no violation of SMTP proper. The server, merely unable to fulfill the request, understood it and is giving the client the choice to try and keep going with both sides still speaking SMTP. However, upon receiving the token "POST", the server should have instead replied with code 500 (Syntax error, command unrecognized) [3], where, on the server's side, the choice to keep going is much harder to justify, since the client obviously isn't even willing to speak SMTP and it is likely that this will not change. : The current implementation is based on this contribution: : https://marc.info/?t=11013155356&r=1&w=2 I remember coming across the documentation for smtpd_forbidden_commands and wondered what that was for. Now I understand that it is a consequence of the interpretation of the example conversation. Perhaps a more suitable name would have been smtpd_forbidden_command_line_tokens , lest people start thinking "POST" is actually an SMTP command. Are there plans to revisit the SMTP command parsing and handling logic in the server in one form or another? Are people making active use of the smtpd_forbidden_commands parameter? Thanks, Mono [1] https://datatracker.ietf.org/doc/html/rfc5321#section-4.2.1 [2] https://datatracker.ietf.org/doc/html/rfc5321#section-4.2.4 [3] https://datatracker.ietf.org/doc/html/rfc5321#section-4.2.2 signature.asc Description: PGP signature
Re: EHLO argument validation
Hello, On 2021-08-09, at 16:33 (UTC+0200), Matus UHLAR - fantomas had the following to say: : I don't know where you got that address is not allowed in helo/ehlo - it is. The (current) standard says that it is for EHLO and it is not for HELO [1]. Thanks, Mono [1] https://datatracker.ietf.org/doc/html/rfc5321#section-4.1.1.1 signature.asc Description: PGP signature
Re: ALPACA writeup
Hello, On 2021-08-10, at 07:39 (UTC-0700), Stephen Satchell had the following to say: : On 8/10/21 7:00 AM, Mono DHS wrote: : > Are there plans to revisit the SMTP command parsing and handling logic : > in the server in one form or another? Are people making active use of : > the smtpd_forbidden_commands parameter? : > : : Longer answer: See this shell sequence: : > # postconf smtpd_forbidden_commands : > smtpd_forbidden_commands = CONNECT GET POST : > # postconf mail_version : > mail_version = 3.4.13 Same here (same version), since it's the default. Anyone added more or other tokens, like, e.g. "EXPUNGE" and "RENAME" (both IMAP), "HAVESPACE" and "SETACTIVE" (both ManageSieve) or anything else imaginable that may or may not be thrown at the server at any point in time? An open door philosophy such as the one implied by smtpd_forbidden_commands does and can /not/ provide protection from the big bad world, even and especially in practical terms. This is simply because it starts with an "anything permitted" policy and only then selectively, more or less arbitrarily, closes the door for specific tokens that have been observed in the wild, perhaps as part of a deliberate action or just misconfiguration. Administrators of such a system are relegated to eternally playing catch-up with the outside world. In contrast, robust protocol implementations are designed according to a constructivist philosophy, starting with a clean slate, "nothing permitted" policy and only ever adding what's permitted by the protocol, and that protocol alone. Any input such a server is presented with that lies outside that protocol definition is rejected outright or dealt with in other ways according to local policy. And the right to reject non-SMTP input follows from operating an SMTP MTA on the well-known TCP port 25, while at the same time holding up the fundamental principle upon which the success of the Internet is based, namely of being liberal in what one accepts and conservative in what one sends. Cheers, Mono signature.asc Description: PGP signature
