Mailgate throws up on valid message

RT Developers
1

Hello RT gurus,

→ resend as we need urgently a solution

this happened on RT3.0.12 - any idea what might have caused this?
We have seen this now several times, e.g. with the attached phishing
spam - but also valid messages. This is 100% reproducible on two
systems, running RT3.0.5rc3 on perl 5.6.1 and RT3.0.12 on perl 5.8.4
with apache1.3+perl_mod.

procmail: Executing “rt-mailgate,–queue,Incident
Reports,–action,correspond,–url,https://localhost/rt3/”
RT server error.

The RT server which handled your email did not behave as expected. It
said:

[…]
no value sent for required parameter ‘message’

Trace begun at
/var/opt/rt3/mason_data/obj/standard/REST/1.0/NoAuth/mail-gateway line 22
HTML::Mason::Commands::ANON at
/opt/perl/lib/site_perl/5.8.4/HTML/Mason/Component.pm line 134
HTML::Mason::Component::run(‘HTML::Mason::Component::FileBased=HASH(0x1e6d784)’)

called at /opt/perl/lib/site_perl/5.8.4/HTML/Mason/Request.pm line 1069
eval {…} at /opt/perl/lib/site_perl/5.8.4/HTML/Mason/Request.pm line 1068
HTML::Mason::Request::comp(undef, undef, undef) called at
/opt/perl/lib/site_perl/5.8.4/HTML/Mason/Request.pm line 338
eval {…} at /opt/perl/lib/site_perl/5.8.4/HTML/Mason/Request.pm line 338
eval {…} at /opt/perl/lib/site_perl/5.8.4/HTML/Mason/Request.pm line 297
HTML::Mason::Request::exec(‘HTML::Mason::Request::ApacheHandler=HASH(0x2016e88)’)

called at /opt/perl/lib/site_perl/5.8.4/HTML/Mason/ApacheHandler.pm line 134
eval {…} at /opt/perl/lib/site_perl/5.8.4/HTML/Mason/ApacheHandler.pm
line
134HTML::Mason::Request::ApacheHandler::exec(‘HTML::Mason::Request::ApacheHandler=HASH(0x2016e88)’)

called at /opt/perl/lib/site_perl/5.8.4/HTML/Mason/ApacheHandler.pm line 792
HTML::Mason::ApacheHandler::handle_request(‘HTML::Mason::ApacheHandler=HASH(0xd51298)’,

‘Apache=SCALAR(0x21c62cc)’) called at /opt/rt3/bin/webmux.pl line 138
eval {…} at /opt/rt3/bin/webmux.pl line 138
RT::Mason::handler(‘Apache=SCALAR(0x21c62cc)’) called at /dev/null line 0
eval {…} at /dev/null line 0

The file
/var/opt/rt3/mason_data/obj/standard/REST/1.0/NoAuth/mail-gateway is
attached.

Investigating the issue, we found that the REST gateway suddenly shut
down during message transmission, therefore leaving “message” undefined.
The script continues to run… We have no clue why this happens.

Best regards,

Ruediger Riediger

Dr. Ruediger Riediger Sun Microsystems GmbH
NSG - SunCERT Komturstr. 18a
mailto:Ruediger.Riediger@Sun.com D-12099 Berlin
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
PGP 2048RSA/0x2C5020E9 964C E189 0FF0 8882 2BAB 65E2 6912 1FF2

mail-gateway (4.58 KB)

bad-spam.eml (8.18 KB)

2

Hello RT gurus,

→ resend as we need urgently a solution

That’s not generally a good way to get answers out of an all-volunteer
list. Also, please don’t cc both rt-users and rt-devel. Most people on
rt-devel are also on rt-users. And getting two copies of a message
doesn’t make anyone more likely to reply to it.

this happened on RT3.0.12 - any idea what might have caused this?
We have seen this now several times, e.g. with the attached phishing
spam - but also valid messages. This is 100% reproducible on two
systems, running RT3.0.5rc3 on perl 5.6.1 and RT3.0.12 on perl 5.8.4
with apache1.3+perl_mod.

Sending unmodified RT source to the list isn’t really something that
will help us debug your issue.
If you have a message that RT won’t process, the only thing we’re going
to be able to use to debug that behaviour is that message itself.
Ideally, we could add it to the test suite to make sure it doesn’t
happen again. Have you folks attempted to isolate which of the message
characteristics cause the failure? Is there anything in RT’s logs?

3

Hello Jesse,

Jesse Vincent wrote:

That’s not generally a good way to get answers out of an all-volunteer
list.

I agree, but I had included more information into the second message as
we were debugging the issue as well. An unmodified resend is surely a
waste of time and bandwidth.

Also, please don’t cc both rt-users and rt-devel. Most people on
rt-devel are also on rt-users. And getting two copies of a message
doesn’t make anyone more likely to reply to it.

Understood!

Sending unmodified RT source to the list isn’t really something that
will help us debug your issue.

I have included the dynamically created /var/opt/… file from
HTML::Mason where the error occurred. This is a state file - no source code.

If you have a message that RT won’t process, the only thing we’re going
to be able to use to debug that behaviour is that message itself.

That’s why I send the second message. The original message contained
information we cannot disclose. “Sanitising” it removed the problem -
the mailgate worked on the sanitised message. Once we had a second
message I can disclose, I was able to append it to the second message.
Therefore the re-send.

Ideally, we could add it to the test suite to make sure it doesn’t
happen again. Have you folks attempted to isolate which of the message
characteristics cause the failure? Is there anything in RT’s logs?

I have added all what is in the logs. Even with “debug” level enabled,
the was nothing else.
That’s the strange thing: the REST mailgate suddenly stopped and
“message” was not assigned any value. No, it’s not the request body
size, that was the first thing to check :slight_smile:

I thought it’s some special character in the message, but all characters
are encoded, so I am at a loss for the cause.

“Snooping” the traffic we see the rt-mailgate send the full message and
the REST gateway receives it, but when checking the “message” variable
at the very next line in the REST code, it’s undef :frowning:

Best regards,

Ruediger Riediger

Dr. Ruediger Riediger Sun Microsystems GmbH
NSG - SunCERT Komturstr. 18a
mailto:Ruediger.Riediger@Sun.com D-12099 Berlin
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
PGP 2048RSA/0x2C5020E9 964C E189 0FF0 8882 2BAB 65E2 6912 1FF2

4

If you have a message that RT won’t process, the only thing we’re going
to be able to use to debug that behaviour is that message itself.

That’s why I send the second message. The original message contained
information we cannot disclose. “Sanitising” it removed the problem -
the mailgate worked on the sanitised message. Once we had a second
message I can disclose, I was able to append it to the second message.
Therefore the re-send.

Please accept my apologies. The generated copy of the mailgate is just
that, generated, so I saw a long attachment that doesn’t really tell us
much. I missed the actual mail attached after it. I’ll see what happens
when I thread this through my testing RT instances.