[Oberon] RFC 5322 and ETH Oberon SMTP.

[Michael Schierl]

Hello,


Am 14.07.2022 um 18:23 schrieb peter at easthope.ca:

> Some of my messages sent by SMTP in the Oberon subsystem of A2 bounce
> with a report such as this.

SMTP is RFC 5321. RFC 5322 is about the message format, which does not
depend on whether it is sent via SMTP, POP3, IMAP, etc.

> <aabbcc at gmail.com>: host gmail-smtp-in.l.google.com[142.250.102.26] said:
>      550-5.7.1 [192.185.50.161] Our system has detected that this message is not
>      RFC 550-5.7.1 5322 compliant. To reduce the amount of spam sent to Gmail,
>      this 550-5.7.1 message has been blocked. Please review 550 5.7.1  RFC 5322
>      specifications for more information.
>      gs16-20020a1709072d1000b00718c7b4cbeasi2856260ejc.991 - gsmtp (in reply to
>      end of DATA command)
>
> The reference to RFC 5322 is non-specific.  Most incidents are for
> Gmail addresses but some other addresses have produced bounces.
>
> Ideas?

As Jörg already suggested, look at the headers/content of the emails,
not at the SMTP protocol itself. I hope that Oberon's Mail
implementation provides a feature to view the headers and raw body of a
sent email (Thunderbird does :D).

I will assume first that the emails do not have attachments, i.e. they
consist of one single text/plain or text/html body part. If the emails
that bounce all contain attachments, I may give you a list of common
gotchas in MIME multipart handling as well.

- All required MIME headers present (MIME-Version, Content-Type,
   Content-Transfer-Encoding in particular)?
- If content-type is text/*, is a charset specified?
- Message-ID and References headers well-formed (in particular, no more
   than one @ sign per ID)?
- Any non-ASCII characters in header fields? They need to be escaped,
   specifying the character encoding.
- Any headers longer than 1000 characters without wrapping the header
   properly, or any body lines longer than 1000 characters without using
   wrapping via either format=flowed or quoted-printable encoding?
- If there are any non-ASCII characters in the body, does the Charset
   and Transfer-Encoding allow these (e.g. no malformed UTF-8 sequences
   if the charset is UTF-8)?

In my experience when building emails manually/programmatically, it is
usually the 1000 character limit that trips off the email servers. But I
have no experience with Oberon's SMTP and/or MIME implementation.


Regards,


Michael