Fix spelling errors

auth.go

@@ -35,7 +35,7 @@ const (
 	// IETF draft. The IETF draft is more lax than the MS spec, therefore we follow the I-D, which
 	// automatically matches the MS spec.
 	//
-	// Since the "LOGIN" SASL authentication mechansim transmits the username and password in
+	// Since the "LOGIN" SASL authentication mechanism transmits the username and password in
 	// plaintext over the internet connection, we only allow this mechanism over a TLS secured
 	// connection.
 	//
@@ -51,7 +51,7 @@ const (
 
 	// SMTPAuthPlain is the "PLAIN" authentication mechanism as described in RFC 4616.
 	//
-	// Since the "PLAIN" SASL authentication mechansim transmits the username and password in
+	// Since the "PLAIN" SASL authentication mechanism transmits the username and password in
 	// plaintext over the internet connection, we only allow this mechanism over a TLS secured
 	// connection.
 	//
@@ -76,7 +76,7 @@ const (
 	//
 	// SCRAM-SHA-X-PLUS authentication require TLS channel bindings to protect against MitM attacks and
 	// to guarantee that the integrity of the transport layer is preserved throughout the authentication
-	// process. Therefore we only allow this mechansim over a TLS secured connection.
+	// process. Therefore we only allow this mechanism over a TLS secured connection.
 	//
 	// SCRAM-SHA-1-PLUS is still considered secure for certain applications, particularly when used as part
 	// of a challenge-response authentication mechanism (as we use it). However, it is generally
@@ -95,7 +95,7 @@ const (
 	//
 	// SCRAM-SHA-X-PLUS authentication require TLS channel bindings to protect against MitM attacks and
 	// to guarantee that the integrity of the transport layer is preserved throughout the authentication
-	// process. Therefore we only allow this mechansim over a TLS secured connection.
+	// process. Therefore we only allow this mechanism over a TLS secured connection.
 	//
 	// https://datatracker.ietf.org/doc/html/rfc7677
 	SMTPAuthSCRAMSHA256PLUS SMTPAuthType = "SCRAM-SHA-256-PLUS"

eml.go

@@ -383,7 +383,7 @@ ReadNextPart:
 		return fmt.Errorf("failed to get next part of multipart message: %w", err)
 	}
 	for err == nil {
-		// Multipart/related and Multipart/alternative parts need to be parsed seperately
+		// Multipart/related and Multipart/alternative parts need to be parsed separately
 		if contentTypeSlice, ok := multiPart.Header[HeaderContentType.String()]; ok && len(contentTypeSlice) == 1 {
 			contentType, _ := parseMultiPartHeader(contentTypeSlice[0])
 			if strings.EqualFold(contentType, TypeMultipartRelated.String()) ||

smtp/auth_login.go

@@ -29,7 +29,7 @@ type loginAuth struct {
 // See: https://datatracker.ietf.org/doc/html/draft-murchison-sasl-login-00
 // Since there is no official standard RFC and we've seen different implementations
 // of this mechanism (sending "Username:", "Username", "username", "User name", etc.)
-// we follow the IETF-Draft and ignore any server challange to allow compatiblity
+// we follow the IETF-Draft and ignore any server challenge to allow compatibility
 // with most mail servers/providers.
 //
 // LoginAuth will only send the credentials if the connection is using TLS

smtp/smtp_test.go

@@ -2163,7 +2163,7 @@ func SkipFlaky(t testing.TB, issue int) {
 }
 
 // testSCRAMSMTPServer represents a test server for SCRAM-based SMTP authentication.
-// It does not do any acutal computation of the challanges but verifies that the expected
+// It does not do any acutal computation of the challenges but verifies that the expected
 // fields are present. We have actual real authentication tests for all SCRAM modes in the
 // go-mail client_test.go
 type testSCRAMSMTPServer struct {