Re: LKML admins (syzbot emails are not delivered)

[Theodore Ts'o <tytso@mit.edu>]

On Thu, Jan 04, 2018 at 12:04:34PM +0100, Dmitry Vyukov wrote:
> 
> The problem is that it's not _me_, it's a computer program which uses
> some mail delivery system which I don't have full visibility into. I
> don't know if it even gets bounce emails (as far as I understand it's
> not LKML that generates them, LKML SMTP server just returns some error
> code and then it's a responsibility of somebody else to represent it
> by a reply email). If the only way to probe the behavior is to send
> actual emails to LKML (which have high chances to be actually
> delivered to all subscribers), it makes testing somewhat problematic.

It looks like you're using the App Engine Mail API.  You can configure
it to get bounce e-mails[1].  From what I can tell looking at the mail
headers, the mail gets sent via an intermediate SMTP host, such as
mail-it0-f69.google.com before it is delievered to vger.  So if vger's
mailer bounces it via an SMTP error, it would be
mail-it0-f69.google.com's responsibility to generate a bounce message,
which you then should be able to catch.

[1] https://cloud.google.com/appengine/docs/standard/go/mail/bounce

You should be able to test this by having your app-engine send a
message to "invalid-address@vger.kernel.org".  I've verified that this
will cause an immediate SMTP error:

554 5.0.0 Hi [74.207.234.97], unresolvable address: <invalid-address@vger.kernel.org>; nosuchuser; invalid-address@vger.kernel.org

If it doesn't, you should file an internal bug report since that's
clearly a bug in the App Engine's mail infrastructure.  If you can't
get satisfaction that way, my recommendation would be to set up an
Linode server (you can't use GCE because GCE blocks outgoing SMTP
connections) to be your mail gateway, and send the notifications from
a domain such as syzkaller.org, where you have full control of your
mail infrastructure, and you don't have to deal with nonsense such as
DMARC.


It also seems to me, looking at other complaints on this thread, that
there is the opportunity for the syzbot to do much more.  For example,
you can see if it repro's on the last released mainline kernel (such
as 4.14) and if so, have the syzbot automatically do a bisection
search, so you can make sure the report goes to the best set of
developers to fix it, a pointer to the guilty commit.

Cheers,

					- Ted