This issue really highlights a tension I've been feeling in swaks for a while. The tool was written to test mail servers. From that perspective, I often feel that I've put _too_ much input validation in it. Wanting to see how a mail server reacts when it is passed 8bit chars in headers without SMTPUTF8 being specified is a completely logical thing to do with swaks, and if I prevent it, I'm reducing swaks' usefulness as a test tool. OTOH, tons of people just use swaks to send mail. It's a relatively lightweight way to get alerts or files off of a server. For this use case, more validation is better. For the longest time I just responded "swaks is a test tool, you're misusing it", but I don't think that's really useful to anyone. My decision instead is that I will support both use cases. I'm not sure how yet, but I think there will be a test mode that doesn't really do any validation (less that it does now) and an MSA mode that does better validation than it currently does.
All that to say, I acknowledge this bug report and have put it on the list to address, but it will likely not be addressed until after the architecture change above is implemented. Thanks --John On Mon, Mar 4, 2019 at 1:48 PM Andreas Metzler <ametz...@bebt.de> wrote: > Hello John, > > I have received the following bug report as > <https://bugs.debian.org/cgi-bin/923702>: > > ----- Forwarded message from Russell Coker <russ...@coker.com.au> ----- > From: Russell Coker <russ...@coker.com.au> > Subject: Bug#923702: swaks lacks support for the SMTPUTF8 command. > [...] > Below is a transcript of my attempt to forge mail from my own domain by > replacing a Roman E character with a Cyrillic character that looks the > same. > > Postfix rejects the connection due to the lack of a SMTPUTF8 on the mail > from > line. > > With the current situation a bare minimum would be to mitigate this issue > by > detcting non-ascii characters in the sender and recipient addresses and > aborting instead of trying to send a non-compliant message. It should not > just quietly send non-compliant messages and wait for the server to report > a > problem. > > # swaks -s localhost -f russell@cokеr.com.au -t russ...@coker.com.au > === Trying localhost:25... > === Connected to localhost. > <- 220 smtp.sws.net.au ESMTP Postfix - by sending email to this server > you agree to the conditions at this URL: > http://doc.coker.com.au/legal/conditions-of-sending-email/ > -> EHLO smtp > <- 250-smtp.sws.net.au > <- 250-PIPELINING > <- 250-SIZE 51200000 > <- 250-ETRN > <- 250-STARTTLS > <- 250-AUTH PLAIN LOGIN > <- 250-AUTH=PLAIN LOGIN > <- 250-ENHANCEDSTATUSCODES > <- 250-8BITMIME > <- 250-DSN > <- 250 SMTPUTF8 > -> MAIL FROM:<russell@cokеr.com.au> > <** 501 5.1.7 Bad sender address syntax > -> QUIT > <- 221 2.0.0 Bye > === Connection closed with remote host. > # idn2 cokеr.com.au > xn--cokr-x4d.com.au > ------ End of forwarded message ---------------------------------------- > > There seem to be two reports/whishlist reports in there, one for just > passing on -f/-t but setting SMTPUTF8 on MAIL FROM when necessary and a > second one for falling back to punycoding when SMTPUTF8 is > not available (or was disabled by a new swaks commandline options) and > only the domainparts are non-ascii. > > Plus a third one for throwing an error otherwise. ;-) > > cu Andreas >
