Missing or invalid angle brackets in mailbox name
SMTP email proxy and relay server
Brought to you by:
graeme_walker
Menu
▾
▴
#97 Missing or invalid angle brackets in mailbox name
Hi,
First of all, thanks for the really practical tool.
I only have a small problem with the software "Broadcom LSI Storage Authority", which I use to monitor the RAID controller. Unfortunately the email function is obviously not implemented according to the standard, see formatting of the "MAIL FROM" email address:
emailrelay: 20240301.221105.160: info: 127.0.0.1; rx<<: "Mail from: foo@bar.vvv"
emailrelay: 20240301.221105.160: info: 127.0.0.1; tx>>: "553 mailbox name not allowed: missing or invalid angle brackets in mailbox name"
Entering the square brackets together with the email address in the TO field of the software, for example, is not successful as all special characters are removed when saving.
Is there a way to "loosen up" the syntax a bit in the EmailRelay?
Regards
Daniel
Ah sorry, and a few corrections: of course I meant angel brackets, not square brackets and I just saw that in #89 the topic was already mentioned -->
"The angle brackets thing was an issue quite a few years ago, but no one complains nowadays so it's not something I am ever going to "fix" (ie. break)."
Well, I'm "complaining", but I don't think that will change anything ;-) ... Anyway, still a nice tool.
If you really want a back-to-the-90s downgrade I have attached a patch for emailrelay v2.5.2.
Hi Graeme, great! Thank you very much!
Good Evening, Graeme!
Sadly I too would like to go "back-to-the-90s"(for more reasons than this though sometimes :D), as I've found a few of my systems also forget these brackets.
I'm not much of a code jockey but I too will be trying the patch you've included, though would like to suggest perhaps it could be added officially as a flagged feature?
--no-angle-bracketsor--rfc-noncompliantcome to mind.Otherwise I think E-MailRelay may be exactly what I'm looking for...as I find myself in need of store-and-forward for a poor connection situation.
Thanks!
There is a 'moral hazard' in pandering to wrongly implemented protocols, but I suppose a run-time option like "--smtp-server-config=allow-broken-clients" might be an acceptable compromise. It would help if you could say why the sending software cannot be fixed or replaced.
With respect to the linked issue (#89), RFC-5321 is quite explicit: "Since it has been a common source of errors, it is worth noting that spaces are not permitted on either side of the colon following FROM in the MAIL command or TO in the RCPT command. The syntax is exactly as given above." Perhaps that 'fix' in emailrelay v2.5.1 should also be enabled only with the same run-time option.
If you need help with patching and building emailrelay I am happy to do so here, and if you want me to do a one-off Windows build I can do that too.
Perhaps, but apparently strict RFC compliance is not a moral held by many other products, as I'm learning this week .
In my use case for home appliances and personal server, the sender cannot be fixed or replaced because it is part of an embedded device or third party product...my printer for first example. Though a major name brand, Brother, it was first to fall afoul of the strict checking, and I have no control over its programming. I was also going to use an outdated Dell iDrac server module which struggles with modern authentication, another reason I was setting up an in-house open relay in the first place.
If it were self-developed software, or a up-to-date product with an active service contract I could coerce fixes from, perhaps fixing the senders would be a viable solution, but as it stands many possible senders are simply outside of my control, and SMTP servers so far are apparently relaxed on this point and do not put up a fight to force the senders to have been made to specification in the first place.
A colleague of mine wrote back to me this morning suggesting I just use Postfix...he assured me the config would not be as daunting as it looks for my needs, which was a big reason I gravitated towards your software, and that it would not block mail for the RFC, upon both points he was right, at least after he sent me more concise instructions :). Likewise, the direct GMail SMTP connection I was using before also did not care, but I'm moving away from them for other reasons.
Therefore, while I greatly appreciate your work and even more so that you would so actively respond, I think my needs(holding messages while internet is out) are met for the moment and I will not trouble you for a custom build. However, if you do consider relaxing the requirements, you might find an eager market amongst home-labbers...with our mix of personal and professional, common and custom hardware and software, we get a wide variety of things that might never normally be found in the same building. And while some will take no less than going all the way and setting up a full blown MTA, some of us really appreciate a good one-liner setup once in awhile.
Thanks again!
Thanks for the justification, I'll provide an opt-in using the --server-smtp-config option for the next release.
New patch for v2.5.2 attached, replacing the one from 2024-03-20. Activated at run-time with "--server-smtp-config=loose".
This is checked in to svn trunk and git master as v2.5.3dev3 and it will go into the next release (2.5.3 or 2.6 TBD). I've gone with "nostrictparsing" as the smtp configuration item name.
This is in v2.6 as "--server-smtp-config=nostrictparsing".
Just ended up using enabling feature today, after discovering a legacy app that unfortunately cant be adjusted.