[Oberon] Duplicate headers in SMTP. Was RFC 5322 and ETH Oberon SMTP.

[Michael Schierl]

Hello Peter,

Am 22.07.2022 um 17:52 schrieb peter at easthope.ca:
>>From schierlm at gmx.de  Fri Jul 15 19:22:23 2022
>> As Jörg already suggested, look at the headers/content of the emails, ...
>
> Here

Where?

> is another "Undelivered" reply from a gmail address.
>
>> This is the mail system at host gateway20.websitewelcome.com. > ...
>> <...... at gmail.com>: host gmail-smtp-in.l.google.com[142.250.102.27] said:
>>      550-5.7.1 [192.185.70.14] Our system has detected that this message is not
>>      RFC 550-5.7.1 5322 compliant: duplicate headers. To reduce the amount of
>>      spam sent 550-5.7.1 to Gmail, this message has been blocked. Please review
>>      550 5.7.1  RFC 5322 specifications for more information.
>>      l21-20020a170906939500b0072b460163d9si5427332ejx.196 - gsmtp (in reply to
>>      end of DATA command)
>
> Note "5322 compliant: duplicate headers." These header fields were
> added by smarthost ccx.websitewelcome.com.
>
>> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
>> X-AntiAbuse: Primary Hostname - ccx.websitewelcome.com
>> X-AntiAbuse: Original Domain - gmail.com
>> X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]

I am sure there are more than these four headers, and I would bet that
there is another one that is duplicated (not necessarily consecutively).
My guess would be Date or Message-ID. But without the full header list,
I won't be sure.

> RFC 5322 doesn't mention the X-AntiAbuse header.  It provides a syntax
> for folding a long header body.  One folded header is an alternative
> to the four X-AntiAbuse headers.

"X-" headers may appear in any order and number, they may even be
duplicated with same content. Refer to "optional field" in RFC5322.

> Refusal to accept a message because it contains a header meant to
> combat spam is perverse but beyond my influence.

The X- header being the reason for refusal is your view of the world.
Post headers or it did not happen. (Feel free to redact values, but keep
all headers).

> Failure of the message to mun.ca is entirely distinct. Blocking all
> messages from a prominent server because of "reputation" doesn't
> strike me as good practise but switching to another server may be the
> only feasible solution.

Using DNS blacklists to block servers which are notorious for spammers
to create accounts without abuse department that can terminate these
accounts within sensible time frames (some days), as well as blocking
servers that allow open relay without authentication is good practice as
well.

Switching to another server is a good solution, if you pay for the
service. That way, you vote with your money and some spam sending
servers will eventually stop existing.

That being said, 192.185.45.210 (the IP your message originated before
it reached ETH's email server) is currently listed in 4 DNS blacklists:

> Listed in hostkarma.junkemailfilter.com, wiki.junkemailfilter.com : 127.0.1.1 - (ttl:2100) [0.3577 sec]
> Listed in all.s5h.net, www.usenix.org.uk : 127.0.0.2 : See http://s5h.net/rbl - (ttl:5) [0.3667 sec]
> Listed in dnsbl.sorbs.net, www.sorbs.net : 127.0.0.6 : Currently Sending Spam See: http://www.sorbs.net/lookup.shtml?192.185.45.210 - (ttl:3600) [3.3963 sec]
> Listed in spam.dnsbl.sorbs.net, www.sorbs.net : 127.0.0.6 : Spam Received See: http://www.sorbs.net/lookup.shtml?192.185.45.210 - (ttl:3600) [4.1373 sec]


So the admins of that MTA should have some desire to get delisted quickly :)


Regards,


Michael