[Oberon] RFC 5322 and ETH Oberon SMTP.
schierlm at gmx.de
Fri Jul 15 19:22:23 CEST 2022
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[126.96.36.199] said:
> 550-5.7.1 [188.8.131.52] 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.
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.
More information about the Oberon