src/sbbs3 mailsrvr.c 1.717 1.718
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv30700

Modified Files:
mailsrvr.c
Log Message:
Typo.


---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

src/sbbs3 mailsrvr.c 1.720 1.721
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv4643

Modified Files:
mailsrvr.c
Log Message:
Fix bug introduced in previous commit of this file (8 months ago):
If the RECIPIENTTOLIST header fields exists and the RFC822 header field
does not exist, that means the original RFC822 "To" field was not MIME-encoded, which is the majority of email. The routine that converted an smbmsg_t to an RFC822 header did not use this new field however (ignored it). Whoops. So multiple recipients were reflect in the To field and the original destination address(es) in the To field weren't passed on either. Thanks, Frank!

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

src/sbbs3 mailsrvr.c 1.722 1.723
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv8466

Modified Files:
mailsrvr.c
Log Message:
REPLYTOLIST gets the RFC8822REPLYTO treatment. It was the last of the MIME-decoded header fields not to be handled appropriately in the mail server.

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

src/sbbs3 mailsrvr.c 1.723 1.724
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv4141

Modified Files:
mailsrvr.c
Log Message:
When creating an FTN netmail message, set the "LOCAL" attribute flag in
the net-attributes header fields.

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

src/sbbs3 mailsrvr.c 1.724 1.725
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv15089

Modified Files:
mailsrvr.c
Log Message:
Set the KILLSENT network attribute for created Internet email messages when enabled in SCFG->Networks->Internet (new option).
Do the same for FidoNet NetMail messages routed via SMTP.
Only auto-delete sent Internet mail messges when either the KILLSENT
network attribute flag is set or there was no SENDEREXT (from_ext) on the sent message.

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

src/sbbs3 mailsrvr.c 1.725 1.726
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv9715

Modified Files:
mailsrvr.c
Log Message:
Don't send mail that has already been sent (but not deleted).

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

src/sbbs3 mailsrvr.c 1.726 1.727
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv17555

Modified Files:
mailsrvr.c
Log Message:
MSG_SENT is in the netattr field, not the attr field. Double-oops. Thanks Dan_C and Nelgin for bringing to my attention.

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

src/sbbs3 mailsrvr.c 1.727 1.728
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv7688

Modified Files:
mailsrvr.c
Log Message:
*always* set the KILLSENT attribute flag on email/netmail received for relay via SMTP (regardless of the Internet/Fido netmail setting in SCFG).
The sender should already have a copy (e.g. in their outbox), if they want to keep it.

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

src/sbbs3 mailsrvr.c 1.729 1.730
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv5122

Modified Files:
mailsrvr.c
Log Message:
Address problem reported by Nelgin via IRC with IPv6 DNS server address:
SEND using auto-detected DNS server address: 2001:4860:4860::
!SEND INVALID DNS server address: 2001:4860:4860::
Fix off-by-one buffer overflow while at it.

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

src/sbbs3 mailsrvr.c 1.730 1.731
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv27071

Modified Files:
mailsrvr.c
Log Message:
Fix: IPv6 address problem reported by Nelgin via IRC.

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

src/sbbs3 mailsrvr.c 1.731 1.732
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv30655

Modified Files:
mailsrvr.c
Log Message:
Revert previous commit: this was not a/the problem.

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

src/sbbs3 mailsrvr.c 1.732 1.733
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv13436

Modified Files:
mailsrvr.c
Log Message:
Add FTN message-ID to SMTP->FTN gated email/netmail messages.
FTN Reply-IDs are not added here (yet).

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/sbbs/sbbs/-/commit/cdf1b613a690c62c3d8d538f
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Add one (lower severity) of cryptlib log messages in the mail server
(e.g. errors become warnings) - I'm tired of seeing this in my
error.log every day:
SEND/TLS ... ERROR 'Received TLS alert message: Handshake failure' (-15) setting session active
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/sbbs/sbbs/-/commit/203935575588938fecb97bf7
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Only over-ride (lower the severity) of the cryptlib log msg for a single case

Add another "get cryptlib error string" (at least, that's what I assume GCES stands for) that allows the log level to be specified, rather than derived
from Cryptlib thinks the log level should be. Do this rather than adding one (lowering the severity) of every cryptlib log message as I did in the previous commit to this file.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/sbbs/sbbs/-/commit/1161e2cfd91d12b76f2d7267
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Reject control chars in base64-decoded auth credentials (name/password)

Also, if getuserdat() fails, don't count that as a failed login attempt.
Also, track username and password of failed-login attempts of deleted or inactive user accounts.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/sbbs/sbbs/-/commit/f4c8a61b08aaa0e073df48cf
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Resolve GCC warning: passing argument 5 of `xpms_accept' from incompatible pointer type
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/sbbs/sbbs/-/commit/68770a4ef6e4826c8c77a1bf
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Address inconsistencies in log message formats.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/sbbs/sbbs/-/commit/6750004aab59e7902c5e2acc
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
RFC[2]821 does not allow a space between MAIL FROM:/RCPT TO: and the <addr>

Weird that no mail server has ever complained; I guess they're all prettty "liberal in what they accept".

Also, eliminated an unnecessary strcpy() call.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/sbbs/sbbs/-/commit/6851910b53701135226934b4
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Add IP address or authenticated user name to SMTP server log messages.

This might not be so great for IPv6 connections (let me know).

Also, use macro for the maximum received SMTP bad command magic number.

Fix-up the sender and recipient info included in log messages in the sendmail thread too.

Bumped rev to 1.735.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/sbbs/sbbs/-/commit/fd4692eade59d264c901fa40
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Exclude authenticated connections from MaxConcurrentConnections limit

Like the Terminal Server, don't count authenticated connections against the MaxConcurrentConnections limit.

Only authenticated users with passwords (not Guest) count as authenticated connections.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/sbbs/sbbs/-/commit/a1aec694f1d420510239a516
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Fix printf format typo.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/sbbs/sbbs/-/commit/816ea9edb2677124f76bcb19
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
More log message overhaul. POP3 CAPA cmd support in transaction state.

Log the IP address first in most log messages.
Condense white-space in log messages to a single space.
Log the server IP address of incoming connections.
(more) Intelligent email address enclosure in angle-brackets.
Better duplicate address comparison (just for log message).
Fix wrong order of lprintf arguments in !UNKNOWN USER log message (new bug). ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/sbbs/sbbs/-/commit/26638e25ade85142b42221b9
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
More log message updates.

Putting IP addresses first.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/sbbs/sbbs/-/commit/8cea25da893d72b9c13bf1ca
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Use a mutex to serial message saving among multiple clients/threads

This work-around shouldn't be necessary, but at least on my Linux/Samba setup, when GitLab sends out notification emails to subscribers and creates 4+ simultaneous SMTP connections and sends email messages, sometimes (often) it ends up with a lock-timeout on the mail base. The file locking should handle the contention fine, but somehow I end up in scenarios where savemsg() takes 30 seconds to complete (the configured SMB lock-timeout is 30 seconds, likely not a coincidence) - and this causes other clients to timeout trying to lock the base. Just use a sharead-mutex here instead as a work-around. The wait time is indefinite, might want to consider using a timed-wait instead.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/sbbs/sbbs/-/commit/d0faa35d1132891d0652eb2d
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Address warning: type defaults to `int' in declaration
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/sbbs/sbbs/-/commit/ba8d544c7f1a3340dd967fd1
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Detect and reject forged "from" fields in submitted msg headers

For non-authenticated SMTP clients, if the "From:" header field contains a "name" which appears to be an email address (i.e. it has an '@' in it), and that address does not match the *actual* address in the "From:" field, reject the mail with an error message about the forged/mismatched address.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/sbbs/sbbs/-/commit/3aacaa64b56053c89bdc9c2b
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Fix sendmail bug introduced in 6851910.

The "MAIL FROM" command argument must always be enclosed in angle-brackets. Some mail servers (e.g. gmail, aol) would reject messages not delivered in this manner, e.g.:
mx-aol.mail.gm0.yahoodns.net replied with:
"501 Syntax error in parameters or arguments tnmpmscs"
instead of the expected reply:
"250 ..."
gmail-smtp-in.l.google.com replied with:
"555 5.5.2 Syntax error. o6si11103060plk.317 - gsmtp"
instead of the expected reply:
"250 ..."
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/sbbs/sbbs/-/commit/d6ec78eb57aad4118cd67879
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
MS Outlook can place names of to/from users in single-quotes

Parse single-quoted "name" portion of email-addr header fields. I don't think this is going to fully solve the issue with FTN netmail gated to SMTP and replied via Outlook, but it's a start. Try that Nelgin.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/sbbs/sbbs/-/commit/24021e05aa64a7c4c84c787a
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
The Received/trace header should contain the forward-path for "for"

instead of the potentially-alias'd delivery address. The angle-brackets
(now included) appear to be standards-compliant.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/sbbs/sbbs/-/commit/22faceeef77fe05b98d707f9
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Better FTN netmail gating support

Revert the previous change to the mailsrvr (don't try to parse the MS Outlook singled-quoted names in to/from header fields).

Instead, use the new matchusername() to perform a liberal name match against the name portion of the destination email address and if it matches, go ahead and use the quoted-name field. Otherwise, use the name portion of the destination address as the TO field for the FTN netmail message.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/b5d19603092a4f4c978e7313
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Connection and logon linked lists need re-init for every recycle

Each list mutex is destroyed in the call to listFree() in cleanup(). Without a call to listInit(), the mutex is not recreated and thus the lists are no longer mutex-protected after a recycle. No negative consequences were observed from this issue, but a potential issue it is (was).
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/dd121bcf7f0a690659ba5858
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Fix bug introduced in c90ba307 - line endings stripped from rx'd mail

An unrelated optimization (elimination of an unnecessary use of fprintf) resulted in a new bug that combined all lines from SMTP-received mail messages into a single long line, thus breaking all decoding ability of multi-part MIME messages (where blank lines are significant).

Went ahead and replaced some other unnecessary uses of fprintf(), replaces with fputs() while at it.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/acede36f01fcda7c4384c776
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Don't support yields per x lines on SMTP receive

Consume the SMTP lines as fast as possible since the sender may be on the
local network (or even local/loopback interface!) and could get way ahead and timeout otherwise, resulting in the "premature evacuation" error (and dumping of the received message) on the receive side. This resolves an observed issue with sending large attachments to the mail server at very high rates and the sending client timing and disconnecting waiting for a response from the server (which was throttling the receive using YIELD).
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

Re: src/sbbs3/mailsrvr.c
By: Rob Swindell to Git commit to main/sbbs/master on Fri Jan 22 2021 06:22 pm

An unrelated optimization (elimination of an unnecessary use of fprintf) resulted in a new bug that combined all lines from SMTP-received mail messages into a single long line, thus breaking all decoding ability of multi-part MIME messages (where blank lines are significant).

Well, that makes perfectly good sense now. I got a couple messages this morning and they were one really long line. Thank you for fixing this. I'll update tonight.

Brian Klauss <-> Dream Master
Caught in a Dream | caughtinadream.com a Synchronet BBS

---
■ Synchronet ■ Caught in a Dream - caughtinadream.com

https://gitlab.synchro.net/main/sbbs/-/commit/84009d35bf2f1295a0407699
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Close the mime part even when error opening file

If there was an error opening a file for attachment, the MIME part would be left unterminated.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/93208aa960574b21dd2c5ceb
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Support quoted filenames in message subjects

"Old style" (e.g. FTN netmail) attachments put the filename(s) in the message subject. Supported quoted-filenames in the message subject (i.e. to support filenames with spaces in them) in addition to the traditional space-delimited filenames. Mixing quoted and space-delimited filenames (for multiple attached files) in a single message subject is supported.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/8c28acaba05ac4cb96d245e4
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Fix exception (crash) when sending file attachments

The new subject line parsing (with quoted-filename support) had a NULL-pointer deref built-in.

Also fixed a few Coverity-reported issues.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/27079b332cf5f21ef40fe1da
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Recognize DNB blacklist exempted email addresses in From fields

Previously, any DNS blacklist-exempt email addresses (in ctrl/dnsbl_exempt.cfg) had to be used in the mail-envelope (the "MAIL FROM:" address) - that doesn't work for all senders that use re-mailers or whatever where you end-up with some *bounce* address as the envelope-sender.

So now, clear the DNSBL results when the From header field is parsed and the sender was in fact an exempt sender. Note: the Subject line will still contain the SPAM tag if the subject was parsed first (came earlier in the message header). May need to address this limitation in the future if it turns out to be a problem (!).

Lowercase the [smtp|smtps]spy.txt log file.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/e9329f6cdac406bf079f4347
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Correct the parse_mail_address() argument order

Issue introduced in previous commit to this file. The name arg(s) comes before the address arg(s).
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/427e1cb4f8a502955459b0f9
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Don't send default MIME Content-type for msgs with attachments

The file attachments, when MIME-encoded, already include a MIME Content-type header field, so don't send another. This should fix issue #233.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/c21d535dc7b127e029c0203a
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Fix observed crashes at end of pop3_thread() and smtp_thread()

"startup" was being deref'd after the caller free'd it because these thread functions were calling thread_down() before calling mail_close_socket(), which deref's startup which was subject to a race condition.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/02448be248a5393ec95d4eaa
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
When logging sender address forgeries, log the address being forged

Helpful for debugging issues with this forgery detection logic (if there are any).
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/56bc209648a1a198b6973384
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Don't allow unauthenticated DNS-blacklisted clients to post on subs

Eliminate some of the infrequent SPAM posts to the SYNCPROG conference. Maybe make this behavior configurable?
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/3c55d333a2103630ec874457
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Include twit-listed sender name in quotes in log message

Since mail server log messages have their white-space condensed, it was not obvious why some sender's name would match a twitlist.cfg line that filters names beginning with a space: "\ *" because the initial space of the sender's name was condensed/combined with space before it in the log message.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/82da48b3887373503a3ee17c
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
If SMTP-transmit-relay is enabled by no relay server, disable

log an error message and disable the transmit-relay in this detected-misconfiguration case.

Fixes issue #315 reported by Nelgin.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/427599b46e19dc809a5fb268
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Fix compile issue in previous commit. <blush>
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/bff956a191a7427dc0acafe4
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Fix host name or IP address-based smtpspy.txt logging

Caught by Coverity-scan (use of uninitialized variable, 'str') :-)
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/304f72934c3e401e7cc92ea8
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Fix issue with smtpspy-listed names added in previous commit

p (which is used after this) points into 'str', so we can't use 'str' as a temporary variable here.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/ce90be9ea7fcacddfd60628c
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Fix corrupted RFC822 msg headers when a header field was > 1024 chars

When sending an SMB message header via SMTP or POP3, some header fields (lines) could potentially be longer than 1024 and yet sockprintf() was limited to sending 1024 bytes (actually 1022 plus CRLF). This could result in some messages not being sent correctly: header field truncated, not CRLR-terminated, and notably resulting in MIME message contents not being decoded properly in a message viewer/reader. Example (Content-Type is part of the previous header field/line):
x-ms-exchange-antispam-messagedata-0:
=?us-ascii?Q?cm9T1Q9G65VC/lKTTqhODKhy5lHT2y6WWMb/WyvJ+EeGEwYmY7ILhzE3yfNM?=
=?us-ascii?Q?KeFWN9T/PqHBya1plKf/sHgaw0iRmI7Hq+u9Dp4bG8OqdniKQlK+Aa27oXMd?=
=?us-ascii?Q?Hly6OEYaSu7jbhGGY89LF0gyRVqquqxkaMfpKvG+h4cQnnu4Tl8YAKeE39a2?=
=?us-ascii?Q?lHW3372ulmb9jvvZU72J2RtZYkuoIr+Wsqhfyuj39wTZ/+C4qKCsYrmTxrki?=
=?us-ascii?Q?fBZ4gMPzWkrcWAr7zPcXBg8bphJJB8VJFUjQyksA3EG4dtH8+TZeEcNNBmHf?=
=?us-ascii?Q?oCGnV9wHr9HszzrSkkZ2GGyh3QZLHAVDNe7wDXSy7HJttZugf9kNqKGeaYQL?=
=?us-ascii?Q?TpljH1aHPe7MiSP9Dmp/xHQ/DWQOZDx5guNS+iMciMt5p5ad+SkQye0hWRhd?=
=?us-ascii?Q?usHvpllclzIee6lxJ0VSPAzHGlAOhtOolrHdDB2ODjvkEzU7L2Fj2f5x7p9q?=
=?us-ascii?Q?9d6sUgSz7vZVx8yyR3KPq3jIX0QUnl0xr2Mix9xcmMNcg0yFLPcznqBdLVa8?=
=?us-ascii?Q?IC7j0+8oy4BjYxr8Z3elxMC2JKq13gPYgR95cwm6hMDiZbMB4EW/J1uJhD/I?=
=?us-ascii?Q?RIIqTZ+Ywt8nKOfXj6/a9Aauf0wN71QKKA+in7KY9oksIhkUGvWOrtJwkVDL?=
=?us-ascii?Q?Q2UFrBBJyQHJgumj5Y+bG8FDk/55IfyV9XYEcsdLL4bCF+HX4QPHZCw4P+li?=
=?us-ascii?Q?bRvN+UxOO8hgXVkgB1q8mNJ62yQuaj0AContent-Type: multipart/alternative;
boundary="_000_SN6PR07MB454477F4C32C66D48BA0B02187A09SN6PR07MB4544namp_"

Solved by using asprintf() instead of snprintf() for dynamic string formatting and allocation in one go. Using realloc() to expand the buffer for the appended/required CRLF.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/b19288125fb9470836cf50af
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Reject SMTP session from any client that sends illegally-long lines

Log a warning message and send a "500 Line too long" before disconnecting any SMTP client that sends lines > 998 characters in length. Technically, we can handle lines up to 1023 characters, but then we could get out of sync with the client if it sends exactly 1023 chars and then a new-line char (which we would interpret as a blank line, separating the message header and body) - so just punt the client who doesn't obey the rules of the protocol.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/7611f92f4057dae1dd11878a
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Resolve new GCC printf-format warning in new log message text
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/4c6cc08369da690cae967264
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Handle illegally-long received SMTP lines better

SMTP commands have a shorter limit (510 versus 998) and the body text line limit needed to account for dot-stuffing.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/2852540e7b592e32195f03b8
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Fix false FORGED mail header 'FROM' field detection/rejection

Pretty much any From field that contains an '@' in the username portion
was subject to comparison to the full email address, but clearly some of
these rejected emails were not forge attempts:

'Chris @ StubHub' vs 'events@mail.stubhub.com'
'Eric S. Raymond (@esr)' vs 'gitlab@mg.gitlab.com'

Fixed by requiring that the sender name is actually a well-formed Internet email address using smb_netaddr_type(), which was also recently improved to
be more accurate.

Unrelated change: include reverse-path (email address for bounces) in ILLEGALLY-LONG body and header line log messages (usually SPAM from what
I can tell).
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/0f4325eece0e65872ce008c9
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Publish SMTP[S] user authentications to the action/login/PROTOCOL topic
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/fb11866c6dadbd6a8d861b77
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Fix potential NULL pointer deref in rblchk(), observed via segfault lately

I'm not sure why this one only started popping up now, but h_addr_list is a NULL-terminated list and it makes perfect sense that the first entry could
be the NULL-terminator.

gethostbyname is obsolete/deprecated and we should address that in a separate commit.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/1f7cd77aef826d3256ae4e2e
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Check return value of fread()
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/f689169a82124f18d5e4ccd9
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Close socket after logging the "REFUSED SESSION from blacklisted server" msg

Fixes issue #670
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/a35cb08fb0a5f69bbe11f010
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Better resource (e.g. client thread) management

My mail server was suddenly and inexplicably creating thousands of SMTPS
client threads, each with a unique remote IP address, and each eventually failing with the rather obscure log message (from cryptlib):
dbg 'Cannot read item from object' (-41) setting session active

Eventually (after not long, really), the server would run out of resources
and fail in weird and wonderful ways (can't malloc, can't create JS runtime
or context, etc.). The max_clients limit (100, as I have it set) wasn't being effectively-imposed on SMTPS connections.

The root-cause: the active_clients (counter) wasn't incremented until *after* the cryptlib/TLS setup for SMTPS connections and SMTPS/TLS connections can
take a long time to fail, resulting in a vulnerability to an effective denial of service attack.

Raise the minimum severity of all cryptlib/TLS log messages from Debug to
Info.

Create wrappers for smtp_thread() [now smtp_client_thread()] and pop3_thread [now pop3_client_thread()] that handle basic resource management (thread counters, active client counters, the client socket).
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/7d9c8624f7d9c5e0fd1cd5a7
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Fix extra decrement of active_clients (added in previous commit)

And fix some use of CRYPT_UNUSED instead of cryptlib session ID.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/f43e852a170d27afdf6e33a4
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
SMTP mail server wasn't RFC 4954 compliant for "AUTH PLAIN" logins

The base64-encoded credentials can either be supplied with the AUTH PLAIN command or in response to a 334 server-challenge. We only supported the
former form and logged a warning ("Missing AUTH PLAIN argument") when we received the latter. No warning is logged now and the appropriate server-challege is sent and the response accepted and base64-decoded and
parsed as before.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/952a25f17aa96355e4c92e95
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
More commonization of "CLIENT BLOCKED" log messages
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/62b866c243d9a8201c55b6fa
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
If cryptInit() fails, just disable TLS support

But continue initializing/running for other non-TLS protocol support.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/fa5ae01239d3488112dae489
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Some more printf formats... mostly off_t but also a size_t and an time_t
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/76055e3d35e795f4ceeefb0e
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Add missing header?
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/f44997570fb796b34f99285f
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Aha! XP_PRIsize_t is a *size*, not a *type*.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/aaa82ca4c9a5aac286603272
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Oh damn, this is an off_t + size_t + 1... talk about the wild west of types!

Both long long and long are reasonable for some mixes of platforms.

Just punt, cast the whole thing to int64_t, and forget about it.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/5cc3767eb1d56bb0db294f86
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Use fnopen() for auto-retry when opening dnsbl_exempt.cfg for append
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/5564eb67e84e55e8a6dcbb0e
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
MIME-encode words that contain non-ASCII values in text header fields

(e.g. to, from, subject) ... when transmitting to other hosts (e.g. POP3 clients or other SMTP hosts).

For messages that contain CP437 or UTF-8 chars in these fields and were *not* imported into the BBS via SMTP or POP3, these header fields would be transmitted to other hosts with the raw CP437 or UTF-8 chars, thus violating POP3 and SMTP protocols and likely resulting in garbage displayed in message readers.

The fix is to encode (using MIME "encoded words", per RFC 2407) where necessary.

Since moderm mail clients (e.g. Thunderbird) don't see to support CP437
charset in MIME encoded header fields, always translate to UTF-8 first.

We probably should be translating message body text to UTF-8 as well, for maximum compatibilty with modern mail readers, but this commit doesn't address body text issues with CP437-encoded content. That'll come later.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/42e9eb8bf7c0d7f338b46d1c
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Allow email.can to contain email sender/recipient *names* as well as addresses

Allow filtering/blocking email based on the name portion of email header fields.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/e6d8053f3457d19d0e456ddb
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Report bigger "size of message" in POP3 LIST response

For messages that have no body, we'd report 0. But RFC 1939 says this value
is supposed to be "the exact size of the message in octets" <sigh>. This
would include header fields, so while we can't know the exact RFC822 size, adding the msg's hdr.length to these values gives size > 0 for messages
with no body text and this enables the Apple iPhone Mail app to download
the message (fixing issue #822).

Part two of this fix is to provide a blank line of message text when there
is none. This changes the message displayed in the iPhone Mail app from:

"This message cannot be displayed because of the way it is formatted.
Ask the sender to send it again using a different format or email program.

text/plain"

to (the much nicer):
"This message has no content".
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/bb3485a9c4e2c36a07aaf512
Modified Files:
src/sbbs3/mailsrvr.c
Log Message:
Include the size of the message headers in the POP3 STAT response too

I suppose if we only had messages with no body text, this value could be 0
(not accounting for any headers) and thus throw a client off.

So consider this as part of the fix for issue #822.
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net