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
