Page MenuHomePhabricator

OTRS does not show the sender-field
Closed, DeclinedPublic

Description

Hello.

The ticket 2016051910008114 has a invalid FROM-address, but a valid Sender-address (this one was also used for the envelope). According to rfc5322 (3.6.2.) the OTRS SHOULD display the Sender-field in this case, but does not.

Of course this is not urgent.

Sincerely,
DaB.

Event Timeline

Restricted Application added subscribers: Zppix, TerraCodes, Matthewrbowker and 3 others. · View Herald TranscriptMay 21 2016, 12:08 PM

I have to assume this needs upstream? Can somebody more technically proficient look into that?

Steinsplitter moved this task from Incoming to Backlog on the OTRS board.May 21 2016, 2:03 PM
akosiaris added a subscriber: akosiaris.EditedMay 23 2016, 1:11 PM

What does invalid qualify as in this specific case ?

Looking at the From: header, it has a syntactically correct email address in it, so that's not it. The domain part does not exist indeed (one very very close to it and belonging to the exact same owner does exist however and is used during the email transmission so I am not ready to take it as a clear cut invalid sign). However even in this case, RFC5322 3.6.2 (and 3 in total) is for the message format syntax and does not dictate what UAs should be doing. And it seems there are some MUAs that do not do that. Thunderbird for example does not

That being said, adding the Sender: header to the displayed fields in OTRS might be useful (and might also be confusing for users). A quick look in the code in https://github.com/OTRS/otrs/blob/ffac6b7f3e0e07eff81d0b25a09d023a5f02ec2c/Kernel/Modules/AgentTicketZoom.pm#L2451 shows that only From, To, cc are being considered for inclusion there. So, I 'd say that probably this needs to go upstream (OTRS devs)

@akosiaris: That the from-address is invalid (as: not usable) is just the reason that the displaying of the sender-field would a good idea (BTW: The OTRS knows that the from is invalid – when you try to reply to it).

The RFC says that “both fields should APPEAR” – in my eyes that means displayed. But I may be wrong.

@akosiaris: That the from-address is invalid (as: not usable) is just the reason that the displaying of the sender-field would a good idea (BTW: The OTRS knows that the from is invalid – when you try to reply to it).

Yes, that happens because when constructing the reply email, it does a DNS check to see if the domain has MX and/or A records. If it fails it returns the message that you witnessed. However, the failure to lookup a DNS MX/A record might very well be because of a transient failure and not a permanent one and can not be relied upon for a permanent result. At the same time it is a relatively expensive operation and should not be done at every article viewing. I think OTRS devs have made a good choice of repeating it in every email sending only, but it also means that check can not be used for much else.

The RFC says that “both fields should APPEAR” – in my eyes that means displayed. But I may be wrong.

The RFC means in the message format syntax, not the user friendly version MUAs display to the user. The entire 3 paragraph is actually riddled with all the technicalities of how to embed dates, how to quote strings, which header to use and when and not how MUAs, like Thunderbird, Outlook or OTRS in this case, should display that data to the user.

akosiaris closed this task as Declined.Oct 5 2016, 7:44 AM

I 'll decline this one. As I 've argumented above, the choice of the OTRS devs to validate emails on sending only (vs every article viewing) is a sound one, while the RFC quoted is for the message format syntax and not the MUAs.