Hi, Torsten -
On 7 February 2017 at 05:01, Torsten Tributh via Exim-users <
exim-users@???> wrote:
> I assume that an email address constructed like:
> mail+user@???
> is legit.
>
Checking against RFC 5321 <
https://tools.ietf.org/html/rfc5321>, the
RFC5321.MailFrom takes an address that, in the RFC, is defined to be a
"reverse path". Following this through the definitions we have
Reverse-path = Path / "<>"
Path = "<" [ A-d-l ":" ] Mailbox ">"
Mailbox = Local-part "@" ( Domain / address-literal )
Local-part = Dot-string / Quoted-string
Dot-string = Atom *("." Atom)
Atom = 1*atext
and RFC 5322 defines an *atext* character as follows
atext = ALPHA / DIGIT / ; Printable US-ASCII
"!" / "#" / ; characters not including
"$" / "%" / ; specials. Used for atoms.
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~"
So I reckon according to the RFCs the address <+@example.org> should be
syntactically valid. (But there is a "but"… see below.)
> I have a very short DATA ACL
>
> deny
> message = No verifiable sender address in message headers
> !verify = header_sender
>
> which rejected now mails, where the envelope-sender and the from-header
> is only having mail addresses including a "+" before @
>
To be very clear, are you saying:
- the version of Exim you were using before (what version was it?) *did
not* complain about the address <+@example.org> in your "!verify =
header_sender" check, but
- the Release Candidate version, Exim 4.89 RC2, *is* complaining about
the exact same address?
As Jeremy says, without knowing the exact unobfuscated address it's
difficult for anyone to confirm the problem: there might be something else
about the actual address that's causing the check to fail, not just it
having only a "+" to the left of the "@".
For example (and I freely admit I might have this wrong), if your routers
are using
local_part_suffix = +*
to allow for so-called "plussed addresses" (a.k.a. "sub-addressing") then
Exim would interpret the address differently: the part to the left of the
"+" being the account's mailbox, and the part between the "+" and "@" being
the sub-mailbox/folder within the account.
I'm not sure what the expected behaviour is in this case, but suspect that
as the address <+@example.org> is effectively stripped down to just <@
example.org> it would then be considered to be invalid — the RFC says there
must be 1 or more *atext* characters in the local part of the address. If
that's the case and Exim didn't used to spot the error but has been
corrected to now do so then that would be a bug being fixed rather than
introduced!
As you can see, people need to know more about your configuration and the
data before anyone can offer any help or advice.
Cheers,
Mike B-)
--
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811 <01904%20323811>
Web:
www.york.ac.uk/it-services
Disclaimer:
www.york.ac.uk/docs/disclaimer/email.htm
