Talk:S-nail

Article cleanup

Current thoughts:

• Although the current headers are creative, they need to be descriptive of what each section contains. See Help:Effective use of headers.
• All inline code should use Template:ic, especially in the S-nail#I'm in! section. See Help:Style#Code formatting.
• There are several configuration files and scripts within the article that could possibly be linked from elsewhere. The biggest use case, mail forwarding from a server, isn't easy for newcommers to see.
• It's difficult and unnecessary to include a changelog of the software in the introduction. I think this should be removed.
• Personal comments should be removed (e.g., "well, a complaint of the ArchWiki maintainer about the content of this page, ugh;").

Rdeckard (talk) 12:25, 19 March 2016 (UTC)

Updated Rdeckard (talk) 12:11, 20 March 2016 (UTC)

I'm working on an updated version here: User:Carpetsmoker/S-nail. Carpetsmoker (talk) 16:26, 29 July 2017 (UTC)

I think this should be worked now. Thank you.

I'm not deep in the subject, but Carpetsmoker's greenfield draft looks promising to me already. It makes me wonder what's the best approach going forward, either merge its more flexible/standard base structure here or cherry-pick from this article and merge it over to the new draft.

Rdeckard, Carpetsmoker, others interested, thoughts? --Indigo (talk) 17:43, 19 August 2017 (UTC)

Can not figure out what does not baffle all descriptions means

Quoting S-nail#Interactive usage

Because it strives for POSIX standard compliance some settings have to be adjusted before using it interactively does not baffle all descriptions, however.

Can you explain what

baffle all descriptions

means? Doesn't Baffle tied to confusion, or inability? Confusion with the POSIX standard? Confusion with the adjusted settings? Sdaoden added it to the article at special:diff/320539. Regid (talk) 00:35, 10 December 2023 (UTC)

Sample config for mailbox.org

It would appear s-nail 14.9.25-1 has problems with URI-encoded passwords which contain some certain subset of special characters; the mailbox.org auto-generation produces passwords like "iM)=bybfirUYT)X3qW6vC;=2S8Bg=:RFvDlpuaTn" which even if encoded 7 ways to Sunday still causes the app to fail claiming it's not percent url-encoded (and then instructs to use an app/method that no longer exists in Arch). This is when using the recommended "set mta=smtps://USER@HOST:SERVER:PORT" config pattern.

After regenerating mailbox.org app passwords and beating on s-nail, there's only one method I could get working - break the elements apart, and then use hard quotes '...' to protect the password content so it gets base64 encoded properly. Don't use URI encoding.

account mailbox {
  set v15-compat=y
  set ttycharset=utf-8
  set smtp-auth=login
  set from=username@mailbox.org
  set user=username@mailbox.org
  set password='generated app password'
  set mta=smtps://smtp.mailbox.org:465
}

Testing with -vv should now show properly read-from-config passwords and proper base64 encoding used to send to the server. Not using hard quotes will lead to s-nail truncating at the semicolon (;) which seems to be very common in mailbox.org generate passwords. Hope this helps the next person along. TE (talk) 15:33, 2 December 2025 (UTC)