Re: [exim] Exim 4.89 RC2 uploaded (openssl-only)

Pàgina inicial
Delete this message
Reply to this message
Autor: Torsten Tributh
Data:  
A: exim-users
Assumpte: Re: [exim] Exim 4.89 RC2 uploaded (openssl-only)
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