Sendmail applet may need to validate on RCPT

[Vladimir Dronnikov]

>> -am<meth> to specify login method
>>
>> http://downloads.openwrt.org/people/nico/man/man8/ssmtp.8.html
>
> I think it's best to act compatibly with it.
>

Bad news :) For it's quirky and not busyboxy.

>
>> And BB sendmail is mainly MUA; however, to be compatible it
>> combines both MUA and MTA options.
>
> I don't understand MUA/MTA slang. I understand "SMTP client",
> "SMTP server", "POP3 client", "POP3 server", same for IMAP.
> Can you rephrase the above for dummies like me?

BB sendmail is not SMTP server; it is SMTP client (cause it talks to
SMTP servers) and is partially a user agent (since it composes mail
messages). Vanilla sendmail, in contrary, can be run in both server
and client modes. To be compatible in option area BB sendmail has to
accept both client and server options. Unless we split BB sendmail
into specific parts.

>
>> So I treat -a for attachment as quite common choice.
>
>> > * "vanilla sendmail"?
>> > * other sendmail clones?
>>
>> They are MTAs, and have nothing to do with attachments.
>
> I don't understand.

None of sendmails (AFAIK) deal with attachments. They just feed its
input to SMTP server. I found (and still find) that it is very useful
to allow to specify attachments without use of additional utilities.
That makes sendmail a solid peace of software.

> In sendmail world, how do they send mail from command line?
> IOW, what is their "SMTP client" program, and how does it
> take attachments?

I just don't know. I didn't use standard utilities at all. My
experience was to write a shell script (I called it mailer) which
composes the mail message given subject, recipients, attachments and
body. I then fed its output to XMail's sendmail helper, which is dumb
enough to take only a couple of options.

> I think there's need to add largish comment to sendmail.c and explain,
> which clones of sendmail are popular in the wild, which options
> they support, which options from those do _we_ support.
> If we have aliases for sendmail applet (or will have, like "ssmtp"),
> and have different options supported for each, that needs to be documented.

Good job.

> If this sounds boring to you, consider how much of confusion
> that will clear up, and sendmail developers will have clearer
> vision what we have now, and what we are trying to emulate.
> Currently, it requires either telepathy or extensive knowledge
> of Linux's command line mail utilities from various projects.

It indeed is boring. But who cares :)

I'm going to split sendmail into parts. This seems the only way to
avoid option hell.

Regards,
--
Vladimir