Hi, Torsten - On 7 February 2017 at 05:01, Torsten Tributh via Exim-users < [email protected]> wrote:
> I assume that an email address constructed like: > [email protected] > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
