Back in 2007, commit 0c97c9d437 ("'simple' error message functions by
Loic Grenie") introduced bb_simple_perror_msg() to allow for a lower
overhead call to bb_perror_msg() when only a string was being printed
with no parameters. This saves space for some CPU architectures because
it avoids the overhead of a call to a variadic function. However there
has never been a simple version of bb_error_msg(), and since 2007 many
new calls to bb_perror_msg() have been added that only take a single
parameter and so could have been using bb_simple_perror_message().
This changeset introduces 'simple' versions of bb_info_msg(),
bb_error_msg(), bb_error_msg_and_die(), bb_herror_msg() and
bb_herror_msg_and_die(), and replaces all calls that only take a
single parameter, or use something like ("%s", arg), with calls to the
corresponding 'simple' version.
Since it is likely that single parameter calls to the variadic functions
may be accidentally reintroduced in the future a new debugging config
option WARN_SIMPLE_MSG has been introduced. This uses some macro magic
which will cause any such calls to generate a warning, but this is
turned off by default to avoid use of the unpleasant macros in normal
circumstances.
This is a large changeset due to the number of calls that have been
replaced. The only files that contain changes other than simple
substitution of function calls are libbb.h, libbb/herror_msg.c,
libbb/verror_msg.c and libbb/xfuncs_printf.c. In miscutils/devfsd.c,
networking/udhcp/common.h and util-linux/mdev.c additonal macros have
been added for logging so that single parameter and multiple parameter
logging variants exist.
The amount of space saved varies considerably by architecture, and was
found to be as follows (for 'defconfig' using GCC 7.4):
Arm: -92 bytes
MIPS: -52 bytes
PPC: -1836 bytes
x86_64: -938 bytes
Note that for the MIPS architecture only an exception had to be made
disabling the 'simple' calls for 'udhcp' (in networking/udhcp/common.h)
because it made these files larger on MIPS.
Signed-off-by: James Byrne <james.byrne@origamienergy.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Implement the -am argument to allow choosing an AUTH method.
For now only PLAIN and LOGIN are supported, but others can be added
easily in the future.
AUTH PLAIN required adding a new variant of encode_base64() capable of
handling NUL characters in the input string; the old function is now a
wrapper for the newer one.
function old new delta
encode_n_base64 - 236 +236
sendmail_main 1199 1380 +181
packed_usage 32873 32877 +4
encode_base64 242 36 -206
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 2/1 up/down: 421/-206) Total: 215 bytes
Signed-off-by: Raffaello D. Di Napoli <rafdev@dinapo.li>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Pointer e needs to be wound back in order to overwrite '>' with '\0'.
Regression introduced in 20077c1429
Signed-off-by: Raffaello D. Di Napoli <rafdev@dinapo.li>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
If a non-starttls helper is in use, initial 220 response is processed by us,
not by helper.
Some servers consider us to be a spammer if we don't wait for it.
It is not in protocol, but it is a real-life problem.
The workaround in this patch is a magic envvar, $SMTP_ANTISPAM_DELAY:
...
-H 'PROG ARGS' Run connection helper. Examples:
openssl s_client -quiet -tls1 -starttls smtp -connect smtp.gmail.com:25
openssl s_client -quiet -tls1 -connect smtp.gmail.com:465
$SMTP_ANTISPAM_DELAY: seconds to wait after helper connect
...
By using it, people can tweak sendmail behavior even if sendmail invocation
is buried in some scripts.
function old new delta
packed_usage 30464 30497 +33
sendmail_main 1185 1206 +21
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/0 up/down: 54/0) Total: 54 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
* explain which server we contact by default
* explain when auth is done
* -t is not implied! remove that from help text
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
RFC 5321 requires the return path to be supplied with a proper domain
name.
Signed-off-by: Kaarle Ritvanen <kaarle.ritvanen@datakunkku.fi>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
When adding To: header, add only a single header. If there are multiple
addresses, make it multiline.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
If the message we are sending already has To: header, don't add a new one.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Support long header fields in To:, Cc: and Bcc: headers.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Headers To:, Cc: and Bcc: may have a list of comma-separated
addresses. Add support for that. Commas inside double quotes are ignored.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
When we extract addresses from the e-mail, try to first check for an
address inside angle brackets.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Leave the original To: and Cc: headers untouched, when we try to extract
addresses from them.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
If we get an address we cannot parse properly, we currently just strip
the unknown characters and still try to send it. This is considered
harmful as the resulting address may still be valid but different from
what the user originally intended.
Instead, skip sending to an address we cannot fully understand and
print the characters what we have scanned so far. Leading and trailing
whitespace is allowed and silently stripped.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
According to RFC 5321 the argument to HELO "contains the fully-qualified
domain name of the SMTP client" or its IP address if no FQDN is available.
BusyBox sendmail uses the NIS domain name instead which, in many cases,
is likely to be the default "(none)". [vda: yes, I checked my machine
and its uts.domainname was indeed "(none)"]
Using the host name is more likely to satisfy the intent of the RFC while
allowing the otherwise unused safe_getdomainname function to be removed.
Signed-off-by: Ron Yorston <rmy@tigress.co.uk>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
