Qmail
[Top] [All Lists]

Re: unable to parse comma-delimited addresses

To: qmail@list.cr.yp.to
Subject: Re: unable to parse comma-delimited addresses
From: Quellyn L Snead <quellyn@lanl.gov>
Date: Wed, 08 Aug 2007 16:56:00 -0600
Delivered-to: sp-com-lists@consult.net
Delivered-to: gmail-qmail@securepoint.com
Delivered-to: sp.com.list@gmail.com
Delivered-to: mailing list qmail@list.cr.yp.to
In-reply-to: <20070808220904.GB5606@aleut.local>
Mailing-list: contact qmail-help@list.cr.yp.to; run by ezmlm
References: <54066.128.165.148.97.1186607646.squirrel@webmail.lanl.gov> <20070808220904.GB5606@aleut.local>
User-agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
Thanks to all who replied, this has helped clear up confusion I had about the header structure.

We are seeing this problem from a different third-party app and I was experimenting with mailx to see if I could reproduce it.

It's clear to me now that qmail is doing exactly what it should, and it's the app that's generating incorrect syntax.

Thanks again,
Quellyn



Kyle Wheeler wrote:
On Wednesday, August  8 at 03:14 PM, quoth Quellyn L. Snead:
In all other respects my qmail implementation seems to be performing as expected ... but I am quite new to running a mail server.

Does anyone have any ideas of what might be going on here?

... why do you expect comma-delineated address lists to be acceptable as arguments to `mail`? According to the man page:

    mail [-eIinv] [-a header] [-b bcc-addr][-c cc-addr] [-s subject]
        to-addr [...] [-- sendmail-options [...]]

Note that it doesn't say "to-addrs", and the syntax used there suggests that multiple addresses should be multiple arguments.

qmail-inject is separating the comma-delineated headers because it's *supposed* to. That's a perfectly valid way of specifying multiple recipients in the To: header, according to RFC 2821, but that has nothing to do with `mail` usage.

It seems like the real question you're asking is: "sendmail accepts undocumented syntax; why doesn't qmail's sendmail emulation accept the same undocumented syntax?" The answer to that is: Sendmail isn't *supposed* to re-parse the addresses that you feed it; that's just asking for trouble. It's accepting invalid email addresses and is using heuristics to transform them into valid ones. This is precisely the mentality and design decision that spammers enjoy exploiting.

I can only think that there is something about qmail's sendmail wrapper that is not emulating some sendmail-ish behavior which the mail utility is expecting, but this seems like a very simple scenario which someone else would have surely seen by now.

Nope. It's not emulating some undocumented sendmail-ish behavior that YOU're expecting. The mail utility is being dumb and simple and is not validating it's input. You've fed /bin/mail an invalid email address and rather than throwing out an error, it dumbly handed it to /usr/bin/sendmail.

Here are some example commands. Which do you expect to work?

    mail test@example.com test2@example.com <msg.txt
    mail 'test@example.com test2@example.com' <msg.txt
    mail 'test@example.com,test2@example.com' <msg.txt
    mail 'test@example.com;test2@example.com' <msg.txt
    mail 'test@example.com:test2@example.com' <msg.txt
    mail 'test@example.com|test2@example.com' <msg.txt
    mail 'test@example.com*test2@example.com' <msg.txt
    mail 'test@example.com#test2@example.com' <msg.txt
    mail 'test@example.com[test2@example.com' <msg.txt

According the mail man page, only the first one is valid. Even the second one *should* fail. But (perhaps to its detriment) /bin/mail does NOT check to make sure the destination address the user has provided is valid. Instead, it assumes that the user knows what he's doing.

So the question is, why do you expect the third one to work, but not the last one? Is it documented anywhere, or does it just *happen* to work even though by all rights it shouldn't?

I guess what I'm getting at here is that just as qmail's sendmail interface is not designed to emulate sendmail's bugs and security holes, it is also not designed to emulate sendmail's undocumented strangenesses.

~Kyle

--
*******************************************************
Quellyn L. Snead
Scientific Computing Resources (SCR) Team
HPC-3 High Performance Computing Systems
Los Alamos National Laboratory
Office: 505-667-4185
Pager:  505-664-5559
*******************************************************


<Prev in Thread] Current Thread [Next in Thread>