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 <
> 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-)
>
--
Torsten
