Hi Mike, thank you for all the details. Just to clarify my actual case. I was seeing an ACL matching what confused me. After i have so many ACL in front, this one was nearly never matching. We recognized, that after the failed delivery, the DNS of the opposite site has changed massively. So when i was looking for that circumstance, i was looking to new DNS information's, which did not match the situation of the ACL matching.
The result is: There is no error in exim. The ACL worked like expected. Debugging happened with false impressions, because of new DNS entries were seen in that moment. Regards Torsten On 02/07/2017 02:37 PM, Mike Brudenell via Exim-users wrote: > 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-) > -- Torsten -- ## 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/
