>> The backend system (apparently it must have a few years on it's back) >> uses addresses like: @YYY.XXX.DK:[EMAIL PROTECTED]
>> Now James hickups at this issuing: >> ERROR smtpserver: Error parsing sender address: >> @YYY.XXX.DK:[EMAIL PROTECTED]: No local-part (user account) found at position 1 >> So to be compliant James actually MUST accept this syntax ;-( >Please see RFC 2821 #3.3, #3.7, and most importantly, #4.1.1.3, which makes >it quite clear that we are entitled to reject with a 550 the RCPT TO command >that provided a source route. If you want to support it by stripping the >source route information, that's fine, but I'm just as comfortable issuing >the 550. Okay, see your point. I missed that paragraph in section 4.1.1.3. Seen from my chair though one of the really great things about James (and what we primarily use it for) is its mail-processing capabilities, so we usually has it set up like a mail-processing router, between the internet and an existing mailserver or other backend system. For this purpose it is a better strategy to strip the routes (the fix is actually quite simple). I will do the fix and commit it. But now as 2.2.0 is getting released. What is the procedure for comitting fixes? Is it better to hold of everything till after the merger with MAIN? Maybe I should just go back and reread the threads on this. I have sort of lost the overall picture of the merger strategy. --Søren -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax: +45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer <at> tietoenator.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
