Some thoughts off the top of my head. Most probably random noise or things you have already thought of.

Is mx1.stlouisfed.org your mail gateway? Is this configured somewhere or picked up automatically? If configured it might help to trace where this variable is used.

Perl module or system call for sending e-mail? I doubt that something is "messing" with the e-mail address. It is more likely that whatever is sending the e-mail tacks on the @mx1.stlouisfed.org to the address for some strange reason.

/Sune

> -----Original Message-----
> From: 'Christian Zimmermann' [mailto:zimmermann@stlouisfed.org]
> Sent: Sunday, April 10, 2016 8:03 PM
> To: Sune Karlsson
> Cc: Thomas Krichel; RAS-run Mailing List; Hayes, Dan -- Dan Hayes
> Subject: RE: [RAS] ReDIF-perl trouble
>
> The latest of the little I was able to figure out.
>
> ReDIF-perl does not seem to be to blame, at least not directly. Updating
> it triggered all sort of other updates, and despite reverting ReDIF-
> perl,
> emails are *not* going out. New registrants and email changes bounced
> hopping within our system.
>
> Emails are typically formatted like
> zimmermann@stlouisfed.org@mx1.stlouisfed.org
>
> but I have seen one split in two like this:
> christian.zimmermann@stls.frb.o@mx1.stlouisfed.org
> rg@mx1.stlouisfed.org
>
> which makes absolutely no sense.
>
> There must be some package that has started messing with those email
> addresses. From the list of updated packages, there is no obvious
> candidate.
>
> Still digging.
>
> And, no, Thomas I cannot give you access to the machine.
>
>
>
> Christian Zimmermann                          FIGUGEGL!
> Economic Research
> Federal Reserve Bank of St. Louis
> P.O. Box 442
> St. Louis MO 63166-0442 USA

> https://mailfilter.sunet.se/canit/urlproxy.php?_q=aHR0cHM6Ly9pZGVhcy5yZX
> BlYy5vcmcvemltbS8%3D&_r=b3J1LXNl&_s=c2tuQG9ydS5zZQ%3D%3D

> @CZimm_economist
>
> On Sun, 10 Apr 2016, Sune Karlsson wrote:
>
> >>> 2) I notice today the ReDIF-perl was not installed on RAS. after
> >>> installation though, emails have broken. the to field is malformed,
> >> for
> >>> example:
> >>>
> >>> The following message to <"Christian Zimmermann"
> >>> <zimmermann@stlouisfed.org>@mx1.stlouisfed.org> was
> >>> undeliverable.
> >>>
> >>> returning to 2.70 fixed the problem, so it has nothing to do with
> any
> >>> external perl module that refreshed during install. I suspect this
> has
> >> to do
> >>> with the following in Parser.pm:
> >>>
> >>> <             'remove_newline_from_values' => 0,
> >>>> #SK            'remove_newline_from_values' => 0, Obsoleted by new
> >>> Unicode processing, newlines are always removed
> >>>
> >>> or at least that is all I can see.
> >
> > There are many differences between 2.70 and 2.74. It's not clear to me
> that they should cause problems with sending e-mails. At least I have
> not experienced any problems.
> >
> > Which process is sending the e-mail, where does it get the e-mail
> address? Perl module for sending e-mail or system call to an external
> process? I suppose an assumption of a newline (or white space) at the
> end of the e-mail address that no longer holds could cause problems when
> building a command line.
> >
> > /Sune
> >