Subject: [TOOLS-DEVELOPMENT] Issue with I-D Submission Tool Authentication Emails

From: Alexa Morris <[email-masked]>
Date: Tue, 10 Jul 2012 15:36:56 -0700

There is an ongoing issue with the I-D submission tool that I'm wondering if we can discuss tomorrow, or on an upcoming tools call. Over the past year we estimate that we've received roughly 40 tickets from users who have submitted an I-D but never received the authentication email. These authentication emails contain a link that the user is supposed to click to approve the posting of the draft, so if the user does not receive the email then the draft does not get posted.  

I understand from Henrik that the emails have been sent by the tool, and so that the issue is very likely on the recipient side. However the issue, which seems to be increasing in both scope and size, is significant enough that I'm wondering if we can determine why so many people are affected. Perhaps there is some sort of tweak we can make to minimize this impact. Alternatively, perhaps we can offer guidance as to what they can do on their side to increase the odds of their receiving the email. 

We have more than one open ticket on this very issue right now. See below for an example:

-----
Subject:	Problems with draft submission
Date:	Wed, 6 Jun 2012 15:19:19 +0100
To:	<[email-masked]>
From:	"Adrian Farrel" <[email-masked]>
Download (untitled) [text/plain 479b]
Hi,

One of the authors is reporting problems with a draft submission.

https://datatracker.ietf.org/submit/status/41685/

They did not receive the email with the verification link.

Important:
Can you please authorise the posting of the I-D.

Sometime:
The same problem seems to have arisen a number of times with authors from the
same company. It is likely their filters are dropping these emails. Any clues
about how we can go about tracking this issue down?

Thanks,
Adrian
----

Thanks,
Alexa

----------
Alexa Morris / Executive Director / IETF
48377 Fremont Blvd., Suite 117, Fremont, CA  94538
Phone: +1.510.492.4089 / Fax: +1.510.492.4001
Email: [email-masked]

Managed by Association Management Solutions (AMS)
Forum Management, Meeting and Event Planning
www.amsl.com <http://www.amsl.com/>

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 11 Jul 2012 01:23:44 +0200

Hi Alexa,

On 2012-07-11 00:36 Alexa Morris said the following:
> There is an ongoing issue with the I-D submission tool that I'm
> wondering if we can discuss tomorrow, or on an upcoming tools call.
> Over the past year we estimate that we've received roughly 40 tickets
> from users who have submitted an I-D but never received the
> authentication email. These authentication emails contain a link that
> the user is supposed to click to approve the posting of the draft, so
> if the user does not receive the email then the draft does not get
> posted.
> 
> I understand from Henrik that the emails have been sent by the tool,
> and so that the issue is very likely on the recipient side.

Correct; every single instance of this which has been brought to my
attention, and I've verified, has showed that the logs at the ietf
server shows that the email has been handed over to the recipients
email server.

> However
> the issue, which seems to be increasing in both scope and size, is
> significant enough that I'm wondering if we can determine why so many
> people are affected. Perhaps there is some sort of tweak we can make
> to minimize this impact. Alternatively, perhaps we can offer guidance
> as to what they can do on their side to increase the odds of their
> receiving the email.

Both a tweak and published advice would be good; I'm somewhat baffled
at the cause of the problem, and would like to find some way of improving
the likelihood of the emails reaching the recipients.

> We have more than one open ticket on this very issue right now. See

Yes.  There was another just today which I verified for Stephanie; in
that case (after I provided the log details) one of the other authors
(not the poster) verified that he had indeed received the email.  But
why does it seem like this has become an issue which pops up much more
often after the submission tool rewrite, I wonder?  Has some change
in the text or headers of the email caused a dramatic change in the
likelihood of spam classification?  I'm bothered by this.

Best regards,

	Henrik

> ----- Subject:	Problems with draft submission Date:	Wed, 6 Jun 2012
> 15:19:19 +0100 To:	<[email-masked]> From:	"Adrian Farrel"
> <[email-masked]> Download (untitled) [text/plain 479b] Hi,
> 
> Important: Can you please authorise the posting of the I-D.
> 
> Sometime: The same problem seems to have arisen a number of times
> with authors from the same company. It is likely their filters are
> dropping these emails. Any clues about how we can go about tracking
> this issue down?
> 
> Thanks, Adrian ----
> 
> Thanks, Alexa
> 
> 
> ---------- Alexa Morris / Executive Director / IETF 48377 Fremont
> Blvd., Suite 117, Fremont, CA  94538 Phone: +1.510.492.4089 / Fax:
> +1.510.492.4001 Email: [email-masked]
> 
> Managed by Association Management Solutions (AMS) Forum Management,
> Meeting and Event Planning www.amsl.com <http://www.amsl.com/>
> 
> _______________________________________________ TOOLS-DEVELOPMENT
> mailing list [email-masked] 
> https://www.ietf.org/mailman/listinfo/tools-development
>

---

From: Dave Crocker <[email-masked]>
Date: Tue, 10 Jul 2012 22:58:25 -0700

> server shows that the email has been handed over to the recipients
...
> likelihood of spam classification?  I'm bothered by this.

Was the other author at the same domain name/email service?

Alas, spam has made mail delivery frequently challenging, due to the 
many and varied layers of filtering that gets done.

Has there been any followup with the folks who did not get delivery, 
trying alternative postings, perhaps to other of their email addresses?

Is there any ongoing monitoring of the public reputation of the machine 
(domain name and IP Address) doing sending from the IETF side?

d/

-- 
  Dave Crocker
  bbiw.net

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 11 Jul 2012 11:59:25 +0200

Hi Dave,

> Was the other author at the same domain name/email service?

Yes.  Good point.

> trying alternative postings, perhaps to other of their email addresses?

Normally the submitter who doesn't see the confirmation email contatcts
the secretariat, who sees that the posting goes through and also asks
me to check whether the email has gone out.  Beyond that, no, not to my
knowledge.

> (domain name and IP Address) doing sending from the IETF side?

Alexa?

Best regards,

	Henrik

---

From: Glen <[email-masked]>
Date: Wed, 11 Jul 2012 08:10:29 -0700

On Tue, Jul 10, 2012 at 10:58:25PM -0700, Dave Crocker wrote:
> Is there any ongoing monitoring of the public reputation of the
> machine (domain name and IP Address) doing sending from the IETF
> side?

>From our end, we check the mail delivery queues several times a day, and
we catch any systems that are refusing or "greylisting" our mail.  We 
frequently catch Yahoo, and, less frequently, Google, doing this, and we
take action immediately to resolve it.  But if the destination servers 
accept the mail, we consider it delivered at this point.

Glen

---

From: Dave Crocker <[email-masked]>
Date: Wed, 11 Jul 2012 08:46:47 -0700

> accept the mail, we consider it delivered at this point.

So here's the meta-problem, which everyone already knows:  due both to 
massive scale and massive abuse, mail delivery has gotten complex and 
problematic, and diagnosing delivery problems now requires proactive 
reputation monitoring and prior registration with major receivers.  (To 
be fair, as a multi-stage distributed process, which means that problems 
often happen later and out of sight, email diagnosis has always been a 
challenge...)

Debugging delivery problems ought to involve collaboration with 
receivers but they tend not to have the resources to respond.

Greylisting is one of a considerable array of control mechanisms.  Given 
that it only introduces delay (temporary SMTP refusal for a few minutes 
up to perhaps an hour or so), it's one of the more benign, if 
irritating, mechanisms.

Most of the others happen post-handoff, are catastrophic, but aren't 
visible to the sending side.

Since there is now a body of non-delivery experience, it might be 
helpful to aggregate information about the problem and see whether any 
patterns appear.

As noted in the earlier message, it might also help to try some 
alternatives when there's a delivery problem, to look for specific 
factors that caused the non-delivery.

d/
-- 
  Dave Crocker
  bbiw.net