This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
auto-dbm quirks
- Previous message (by thread): DB RPSL migration task force
- Next message (by thread): auto-dbm quirks
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Steven Bakker
steven at icoe.att.com
Thu Sep 21 12:23:05 CEST 2000
Hi folks,
A few people have asked me to help them out with a nasty problem they're
having. They are stuck behind a braindead ms-exchange server and corporate
standards apparently prevent the use of SMTP, POP or IMAP. Hence, these
people have to communicate using the Exchange protocol. Now, when the
Exchange server has to send mail to the real^H^H^H^Houtside world, it will
use a pesky "connector". And here's the catch: that connector has been
configured to send mail as both plain text _and_ HTML, resulting in, you
guessed it, one of those wonderful "multipart/alternative" hybrid freaks
(can you tell I'm not a fan?).
So, what's the big deal, you ask? These friends of mine are trying to send
updates to the RIPE database, making do with the crummy mail software
they have at their disposal. Unfortunately, the auto-dbm robot does not
understand multipart/alternative, nor any other MIME encoding. In fact,
as far as I can tell from its diagnostics, it completely ignores any
Content-Type: header and simply treats the message as plain text.
Now, I agree, the Exchange mail setup leaves a lot to be desired, but the
mail it sends out _is_ standards compliant. The auto-dbm is the one that's
non-compliant. There are two ways that I can see to fix this:
1. Look for a content-type:- header and INSIST on text/plain.
This doesn't solve my friends' problems, but it would at least
provide more intelligent diagnostics.
2. Do some MIME parsing, allowing both text/plain and multipart/alternative.
In the case of multipart/alternative, INSIST on a text/plain part.
Maybe even decode base64 or quoted-printable? Would be handy in case
there are more crummy mail systems out there...
I don't think the MIME parsing would be so difficult. Decoding base64 or
quoted-printable shouldn't be that hard either.
Is this something that can be done quickly, or at least put on a priority
list? I foresee that in the near future more people will be forced to
embrace the MS-Office dogma and suddenly find they cannot update their RIPE
objects anymore.
Cheers,
Steven
- Previous message (by thread): DB RPSL migration task force
- Next message (by thread): auto-dbm quirks
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]