>> But Brandon works for Google. The subject of this thread is "Delivery to
>> Gmail". It isn’t about his customers, and it isn’t about emails to end users
>> at all. It’s about how Google respond with an SMTP reject, in the SMTP
>> conversation, to a particular temporary DNS error. Some of us woul
On Mon, Dec 14, 2015 at 6:01 AM, Ian Eiloart wrote:
>
> > On 14 Dec 2015, at 08:06, David Hofstee wrote:
> >
> > I am not confusing them. That would be weird.
> >
> > I am saying, to Brandon FWIW, that their users may be a little bit like
> our customers (ie often not technical).
>
> But Brandon
gt; Aan: David Hofstee
> CC: mailop@mailop.org
> Onderwerp: Re: [mailop] Delivery to gmail via IPv6
>
>
>
> On Fri, Dec 11, 2015 at 3:59 AM, David Hofstee wrote:
> That’s why, in ESP parlance, there are two sorts of bounces, to keep it
> simple:
> -
address doesn’t work (any more)
David
Van: Franck Martin [mailto:fmar...@linkedin.com]
Verzonden: vrijdag 11 december 2015 18:14
Aan: David Hofstee
CC: mailop@mailop.org
Onderwerp: Re: [mailop] Delivery to gmail via IPv6
On Fri, Dec 11, 2015 at 3:59 AM, David Hofstee
mailto:da...@mailplus.nl
On Fri, Dec 11, 2015 at 3:59 AM, David Hofstee wrote:
> That’s why, in ESP parlance, there are two sorts of bounces, to keep it
> simple:
>
> - Hardbounces: The recipient address does not work. Contact
> through other means.
>
> - Softbounces: This email did not arrive. Try agai
e actionable for a sender, in
>> a message, is when the content gets unacceptable (spam, too big).
>>
>> We have about 30 categories to explain what type of error occurred
>> (available on request).
>>
>> Met vriendelijke groet,
>>
>>
>> David Ho
--Oorspronkelijk bericht-
Van: Ian Eiloart [mailto:i...@sussex.ac.uk]
Verzonden: vrijdag 11 december 2015 15:07
Aan: David Hofstee
CC: mailop@mailop.org
Onderwerp: Re: [mailop] Delivery to gmail via IPv6
I wonder why they don’t use the terminology from the RFCs: "reject", "defer
t;
> Met vriendelijke groet,
>
>
> David Hofstee
> Deliverability Management
> MailPlus B.V. Netherlands (ESP)
>
> Van: mailop [mailto:mailop-boun...@mailop.org] Namens Brandon Long
> Verzonden: donderdag 10 december 2015 22:23
> Aan: Dave Warren
> CC: mailop
>
Verzonden: donderdag 10 december 2015 22:23
Aan: Dave Warren
CC: mailop
Onderwerp: Re: [mailop] Delivery to gmail via IPv6
I was just discussing this issue with our support folks, and we're looking at
improving ours for this reason. We also see a remarkable number of our NDRs
marked as
> On 10 Dec 2015, at 18:43, Franck Martin wrote:
>
> It also has to do with people not understanding DSN. Seriously they are ugly
> and hard to find the relevant information in them...
Agreed, but if the recipient doesn’t understand the message, and doesn’t act on
it, then it doesn’t matter w
Also bounce.io , but these are very bad services. They bounce to the reply
to, not bounce address: former is likely monitored, latter is likely
automated removal.
On Dec 11, 2015 10:40 AM, "Franck Martin" wrote:
> There a whole business, https://betterbounces.net, based on rewriting the
> NDR int
There a whole business, https://betterbounces.net, based on rewriting the
NDR into something any user can read, with a meaningful call to action.
I love the technical info too, but as Brandon said, it could be later in
the email.
On Thu, Dec 10, 2015 at 1:23 PM, Brandon Long wrote:
> I was just
And unfortunately the friendlier they are, the less useful they usually are.
The ugly ones are the only ones that are useful, but for whatever
reason, it's beyond MTA developers to start with friendly messages with
a "Troubleshooting information below" that contains a useful transcript.
As a
It also has to do with people not understanding DSN. Seriously they are
ugly and hard to find the relevant information in them...
On Thu, Dec 10, 2015 at 2:11 AM, Ian Eiloart wrote:
>
> > On 8 Dec 2015, at 18:31, Franck Martin wrote:
> >
> > Yes, reject
> >
> > It seems that email systems that
> On 8 Dec 2015, at 18:31, Franck Martin wrote:
>
> Yes, reject
>
> It seems that email systems that send you a DSN because of a temporary
> rejection are becoming rarer…
Well, that might be an artefact of more reliable mail systems, and market
concentration around medium and large mail prov
Hi Tony,
At 05:39 08-12-2015, Tony Finch wrote:
This isn't competing standards, this is a fundamental feature of one
standard. Ian is prefering to use exactly the same terminology as
RFC 5321 section 6.2:
If they cannot be delivered, and cannot be
rejected by the SMTP se
Yes, reject
It seems that email systems that send you a DSN because of a temporary
rejection are becoming rarer...
On Tue, Dec 8, 2015 at 3:19 AM, Ian Eiloart wrote:
>
> > On 7 Dec 2015, at 23:56, Franck Martin wrote:
> >
> > Also, often than not, the MTA moves on, and don't wait for an answer
David Hofstee wrote:
> Ian Eiloart wrote:
> >
> > ... I prefer to call that a rejection rather than a bounce. ...
>
> https://xkcd.com/927/
This isn't competing standards, this is a fundamental feature of one
standard. Ian is prefering to use exactly the same terminology as
RFC 5321 section 6.2:
https://xkcd.com/927/
-Oorspronkelijk bericht-
Van: mailop [mailto:mailop-boun...@mailop.org] Namens Ian Eiloart
Verzonden: dinsdag 8 december 2015 12:20
Aan: Franck Martin
CC: Brandon Long; Tony Finch; mailop
Onderwerp: Re: [mailop] Delivery to gmail via IPv6
... I prefer to call that a
> On 7 Dec 2015, at 23:56, Franck Martin wrote:
>
> Also, often than not, the MTA moves on, and don't wait for an answer from the
> DNS resolver. It happens even more with DNSSEC, cf
> https://www.dns-oarc.net/oarc/services/replysizetest.
>
> I tend to agree bouncing the message now, rather t
Also, often than not, the MTA moves on, and don't wait for an answer from
the DNS resolver. It happens even more with DNSSEC, cf
https://www.dns-oarc.net/oarc/services/replysizetest.
I tend to agree bouncing the message now, rather than have it in the queue
for 4 days, lead to faster fix... Many p
> On 7 Dec 2015, at 17:59, Brandon Long wrote:
>
> Is a DNSSEC failure like this really going to resolve itself in 3-7 days?
> Are you even going to know there's an issue if the message is just sitting in
> a queue instead of delivering or bouncing?
Well, yes, because of course we’ll be sen
Brandon Long wrote:
>
> I won't claim our failure mode here is correct for all cases, but the flip
> side is, this is what you get with dnssec by design.
By design the DNS distinguishes between nonexistent (i.e. NXDOMAIN or
NODATA) and failure (SERVFAIL). If there is a security error DNSSEC gives
Franck Martin wrote:
> It depends if it is at connection time, or after the RFC5321.MailFrom where
> the SPF can be evaluated. If there is no valid rDNS and no SPF, rejecting
> after SPF evaluation may not be a bad solution,
If there is a DNSSEC failure you can't tell whether or not there is any
It depends if it is at connection time, or after the RFC5321.MailFrom where
the SPF can be evaluated. If there is no valid rDNS and no SPF, rejecting
after SPF evaluation may not be a bad solution, as anyhow in a great
majority of cases it aint going to be fixed during all these retries, till
the e
Franck Martin wrote:
> http://dnsviz.net/d/5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.7.2.0.0.1.0.0.0.0.0.1.5.0.4.2.ip6.arpa/dnssec/
Gmail should treat that as a temporary error not a permanent one.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Biscay: Southwesterly 5 or 6 in northwest, otherwise, nor
Hi Ted,
At 18:00 03-12-2015, Ted Cooper wrote:
So whomever runs 0.4.2.ip6.arpa has screwed up their key roll over and
the entire branch is now unsigned?!
organisation: APNIC
Anyone know who to poke to get that fixed?
APNIC is a RIR. You can send an email to their helpdesk. Feel free
to dro
We're dependent on the honest DNS folks, and have talked to them about the
possibility of them returning us expired data in the case of server errors,
but they haven't been too excited by the possibility.
And you should note that even coming though in via ipv4 may not outright
reject, but it heav
On 04/12/15 11:10, Franck Martin wrote:
> check
> http://dnsviz.net/d/5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.7.2.0.0.1.0.0.0.0.0.1.5.0.4.2.ip6.arpa/dnssec/
That's a DNSSEC error on servers that are so far out of reach they may
as well be on mars. That makes things a little difficult to fix, or even
tr
check
http://dnsviz.net/d/5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.7.2.0.0.1.0.0.0.0.0.1.5.0.4.2.ip6.arpa/dnssec/
On Thu, Dec 3, 2015 at 4:14 PM, Ted Cooper
wrote:
> I'm starting to conclude that attempting IPv6 delivery to gmail servers
> is simply not worth the electrons.
>
> Understandably, gmail ha
I'm starting to conclude that attempting IPv6 delivery to gmail servers
is simply not worth the electrons.
Understandably, gmail have rules in place for the PTR/ RR of sending
IPv6 addresses. I have no issue with these, as setting them up is
MailServers-100 (Not even the 101) and, I use such c
31 matches
Mail list logo
