Hi Heiko, All
> Exim ignores the part preceeding and including the first ':'.
Yes, that's the thing....it ignores the address altogether
> But, I'm not sure, if such an address is legal per the curreent RFCs.
Yes, it is an illegal address.
>
> > Exim returns a 250 response, even when the source IP is not an authorised
> > IP and when domain2.com is not an authoritative domain.
>
> What is an 'authoritive' domain?
Sorry, my bad use of the language, a domain for which the MTA is configured to accept mail.
>
> > The interesting thing is, that if you do:-
> > RCPT TO: user@???:user@???
>
> > Exim correctly fails the RCPT TO command with a 500 error,
>
> This whould invalidate my statement above. But my version of exim
> refused such address:
>
> mx:~# exim -v -bt info@???:hs@???
> syntax error: malformed address: :hs@??? may not follow
> info@???
I get the same too when I use the command-line -bt option, but in a telnet session it gives me the 501 message.
>
> > But where the user-part is missing from the address, it appears that the
> > address is silently ignored, and the mail is then processed against address
> > user@??? with no sign of anything untoward ever happening in
> > the logs.
>
> Yes. See above, the first part is ignored, currently I do not know why.
> Because we follow RFCs? Because the parsing is buggy? We'll have to look
> at it more closely.
>
If you could please :-) I am not questioning whether Exim follows RFCs, I am puzzled as to why it silently drops input data, invalid input data without throwing some kind of error or warning.
>
> Yes, it seems that the first case '@example.com:user@???' gets
> parsed into user@???, thus you can't find it in your ACL. But, I
> believe there is some variable containing the complete command arguments
> from the current SMTP command, maybe you can check this.
I will indeed see if I can tease the original data out of the transaction through an appropriate variable.
