Sendmail applet may need to validate on RCPT

[Vladimir Dronnikov]

>
> I don't see why do you want to accept server options.
> This can only fool users (so it's worse than useless, it's harmful).

Previous reading of sendmail compatibility (a few months ago) ended
with "we should be as compatible as we can". This I treated as "accept
but ignore options we do not implement". So I put a union of options I
ever found in various sendmail mans to getopt32(). Now I see it only
bloated and fools people. A good lesson, I'd say.

Let's define the set of BB sendmail options we must support. I'd name:
* -o: in particular, "-oi" is implied;
* -t: read recipients from the message and add them to those given on
cmdline. I think it should be implied as it is the major case;
* -f sender: what to specify in MAIL FROM.

We also will support BB extented network parameters: -H 'connect
helper' xor -S 'server[:port]', and -w 'network timeout'.

That is all. Comments?

>> None of sendmails (AFAIK) deal with attachments. They just feed its
>> input to SMTP server.
> This is ok *if* there is no popular program which does that already.
> You can invent API yourself then.
>
> If there is such utility, then mimic it.
>

Right. I know only one attachment dealer -- makemime -- but its syntax
is not very evident. Nevertheless, we have makemime applet.

>>
>> I'm going to split sendmail into parts. This seems the only way to
>> avoid option hell.
>
> As I see it from googling, both sendmail and ssmtp accept
> input from stdin. Then, you can split message creation
> and message sending like this:
>
> makemail -a ATTACH -b BODY -f FROM -t TO -c CC | sendmail/ssmpt ...
>
> where makemail is either your own invention with your own API,
> or a "compatible" clone of something existing already.

Sure. That is what I want to realize. To get rid of sendmail rudiments.

Regards,
--
Vladimir

> --
> vda
>
>