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/[email protected]/
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 ]