“empty” mail (possible unimportant bug)

“empty” mail (possible unimportant bug)

[sirjofri+ml-9front]

Hey all,

occasionally I receive “empty” mails on my upas/smtp server (9front). Looking at the mail in /mail/box/ it looks like this:

 From gmail.com!koepketemi17ixibs Fri Oct  2 11:16:06 CES 2020
Received: from gmail.com ([104.148.61.185]) by oat; Fri Oct  2 11:16:06 CES 2020

(followed by two empty lines)

I don't claim this mail has anything to do with gmail and I don't know the username/email address. Oat is my machine. Generally I just delete these mails, they don't break anything. So this is just for your information.

I know there were some changes in the last weeks (at least new tmdate) and it's possible that this bug is already fixed (by accident). I'll just try updating and hope my imap still works.

sirjofri

Re: [9front] “empty” mail (possible unimportant bug)

[ori]

> Hey all,
> 
> occasionally I receive “empty” mails on my upas/smtp server (9front). Looking at the mail in /mail/box/ it looks like this:
> 
>  From gmail.com!koepketemi17ixibs Fri Oct  2 11:16:06 CES 2020
> Received: from gmail.com ([104.148.61.185]) by oat; Fri Oct  2 11:16:06 CES 2020
> 
> (followed by two empty lines)
> 
> I don't claim this mail has anything to do with gmail and I don't know the username/email address. Oat is my machine. Generally I just delete these mails, they don't break anything. So this is just for your information.
> 
> I know there were some changes in the last weeks (at least new tmdate) and it's possible that this bug is already fixed (by accident). I'll just try updating and hope my imap still works.
> 
> sirjofri

I've seen similar emails -- but they were arriving at an OpenBSD
box, and showed up as empty in Unix clients when I sanity checked
upas/fs. I've been blaming them on incompetent spammers.

So, a few questions:

- Does this happen regularly?
- Is there any typical source email for this?
- Does the raw data in /mail/box/... also seem empty?

If it turns out to happen regularly enough to be worth looking at
more deeply, maybe we could patch smtpd to tee off the raw smtp
session bytes into /sys/log.

Re: [9front] “empty” mail (possible unimportant bug)

[sirjofri+ml-9front]

Hey ori,

The quoted mail is from /mail/box/username/mbox/stuff.

The log line (/sys/log/smtpd) is this:

oat Oct  2 11:16:06 ++[gmail.com/104.148.61.185] blocked: mail refused: 
illegal header chars: fd out of range or not open

Seems like the mail is indeed refused and thus empty, but it still 
creates an empty mail in /mail/box.

Looking in my logs this line happened:

- Aug  8 05:00:34
- Aug 11 16:47:36
- Aug 19 10:00:25
- Aug 19 20:38:22
- Sep 23 03:57:22
- Oct  2 11:16:06

All these requests are from different gmail servers.

02.10.2020 14:16:47 sirjofri+ml-9front@sirjofri.de:
> occasionally I receive “empty” mails on my upas/smtp server (9front). 
Looking at the mail in /mail/box/ it looks like this:
>
> From gmail.com!koepketemi17ixibs Fri Oct  2 11:16:06 CES 2020
> Received: from gmail.com ([104.148.61.185]) by oat; Fri Oct  2 11:16:06 
CES 2020
>
> (followed by two empty lines)

Re: [9front] “empty” mail (possible unimportant bug)

[ori]

> Hey ori,
> 
> The quoted mail is from /mail/box/username/mbox/stuff.
> 
> The log line (/sys/log/smtpd) is this:
> 
> oat Oct  2 11:16:06 ++[gmail.com/104.148.61.185] blocked: mail refused: 
> illegal header chars: fd out of range or not open
> 
> Seems like the mail is indeed refused and thus empty, but it still 
> creates an empty mail in /mail/box.

Ok -- that's a bug, but it makes sense. That error comes from
smtpd.c:/^pipemsg(), which means we've already started feeding
it into the delivery pipeline. don't think we're losing messages,
just creating spurious empty ones.

I'm not sure when I'll get to it, but I think it'll be easy enough
to do -- maybe kill the process we're piping to on a garbled message,
or don't open the pipe until we've parsed the headers.

Re: [9front] “empty” mail (possible unimportant bug)

[Lyndon Nerenberg]

sirjofri+ml-9front@sirjofri.de writes:

>  From gmail.com!koepketemi17ixibs Fri Oct  2 11:16:06 CES 2020
> Received: from gmail.com ([104.148.61.185]) by oat; Fri Oct  2 11:16:06 CES 2
> 020

That IP address has no reverse DNS.  Whois says the enclosing /24
belongs to:

  WebXury Inc WEBXURY-INC (NET-104-148-61-0-1) 104.148.61.0 - 104.148.61.255

The "gmail.com" part of the Received header is what the client
supplied in the EHLO command, and is obviously bogus.

This is almost certainly a spammer validating RCPT TO addresses.  Or one
with very buggy client software.

--lyndon