Hello Gilles, Thank you for your answer. For the first point I have this ruletable domains file:/etc/mail/domains table users file:/etc/mail/users accept tagged CLAM_IN for domain <domains> virtual <users> deliver to maildir "/var/mail/vmail/%{rcpt.domain}/%{dest.user}/Maildir" In /etc/mail/domains I havemydomain.org In /etc/mail/users I haveu...@mydomain.org _vmail I read a few times what you wrote and- "all variations of cases within the domain will match that rule as they refer to the same domain" => I agree- "they will all deliver to the same local user as far as OpenSMTPD is concerned" => With virtual users it didn't work like that for me when I wrote the message so after your email I did tests and search and saw this option %{dest.user:lowercase} which seem to solve my problem. >From what I understood in the RFC, upper case and lower case should be the >same for the user part and I shouldn't have had to specify that lowercase >option, it should have worked by default in my humble opinion and if my >understanding in english is correct.
For my second point the %{rcpt.domain:lowercase} option solved my problem Thank you for these explanations Le Dimanche 29 janvier 2017 17h09, Gilles Chehade <gil...@poolp.org> a écrit : On Sat, Jan 28, 2017 at 09:35:01PM +0000, Mik J wrote: > Version: OpenSMTPD 5.9.2 > Hello, Hello, > I know that my version is not the latest but my question might still be valid. > * > The RFC5321 states in paragraph 2.4 that "Mailbox domains follow normal DNS > rules and are hence not case sensitive."But when I write to emails like > u...@mydomain.org or u...@mydomain.org or u...@mydomain.org they arrive in > different subdirectories# lsMyDomain.org?? mydomain.org MYDOMAIN.ORG > so it seems to me that opensmtpd doesn't follow the RFC This is not correct and slightly out of context. Let me clarify: "Mailbox domains follow normal DNS rules and are hence not case sensitive." This means that sending to x...@opensmtpd.org or x...@opensmtpd.org is essentially the same and implies that the MX handling opensmtpd.org will also handle the OpenSMTPD.org and oPENsmtpd.ORG domains. As far as OpenSMTPD goes, if your smtpd.conf states: accept for domain opensmptd.org [...] Then all variations of cases within the domain will match that rule as they refer to the same domain and they will all deliver to the same local user as far as OpenSMTPD is concerned. There is no violation of the RFC here. Your problem, which I'm going to guess because you didn't show a config, is in how you declared the delivery should take place once the message has been accepted. > * > The RFC also states this"The local-part of a mailbox MUST BE treated as case > sensitive." > How can I ignore the case sensitive in the local part (the name) ? > You can't. While RFC states that the local-part of a mailbox MUST BE treated as case sensitive, it also states a few paragraphs earlier: [...] due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address. Which essentially means that as long as a node is not a final destination it must not try to make sense of addresses and forward them AS IS but the final destination may have its own semantics assigned to the local-part. The local-part is the part before the @ in the email address. As far as OpenSMTPD goes: 1- during the SMTP transaction the domain is considered case-insensitive as I explained above and the local-part is considered case-sensitive, the envelope we save on disk retains the case for both parts. 2- if the mail is to be relayed, the address is forwarded AS IS using the same case as it had when we received it. 3- if the MX is the final destination, then our semantics is to fold the user-part to lowercase and consider that OpenSMTPD only knows how to deliver to system usernames that are all lowercase. In all cases, the address as displayed in DATA part of mail (in headers) will retain the case it had when submitted. You can't alter the behavior for 3, it is a design decision that we took to keep code simpler, less error and ambiguity prone and we have no intent to change that. -- Gilles Chehade https://www.poolp.org @poolpOrg