[TriLUG] Email Problems
Aaron Joyner
aaron at joyner.ws
Fri Feb 8 22:24:07 EST 2013
I hate feeling like I left something unfinished / unconfirmed. RFC
5321 explicitly admits that dropping mail is permitted, but strongly
discourages it. I'd encourage you to read the full text of section
6.2 if the topic interests you (it's pretty short). I'll inline the
particularly relevant bit here:
http://tools.ietf.org/html/rfc5321#section-6.2
-----8< snip 8<-----
As discussed in Section 7.8 and Section 7.9 below, dropping mail
without notification of the sender is permitted in practice. However,
it is extremely dangerous and violates a long tradition and community
expectations that mail is either delivered or returned. If silent
message-dropping is misused, it could easily undermine confidence in
the reliability of the Internet's mail systems. So silent dropping of
messages should be considered only in those cases where there is very
high confidence that the messages are seriously fraudulent or
otherwise inappropriate.
-----8< snip 8<-----
Do let us know how your escalation w/ the ISPs goes,
Aaron S. Joyner
On Fri, Feb 8, 2013 at 11:41 AM, James Jones <jc.jones at tuftux.com> wrote:
> Thanks Aaron. I knew that I could count on you!!!
>
> jcj
>
> On Fri, Feb 8, 2013 at 11:29 AM, Aaron Joyner <aaron at joyner.ws> wrote:
>> A mail exchanger (MX) which accepts mail, and then throws it on the
>> ground, is fundamentally broken. Forgive me for being lazy and not
>> chasing down the RFC, but I'm relatively certain that violates the
>> basic premise of reliable delivery of SMTP. Regardless, some MXes do
>> that. Particularly it's common if the MX spam-scores the message and
>> it registers as "off the charts", it's common to throw it on the
>> ground to avoid back scatter (spamming of some poor unrelated party
>> just because the spammer forged their From: address). This is the
>> primary reason that, when possible, an MX should spam scan, score, and
>> decide to accept or reject messages *before* returning "250 Message
>> accepted for delivery." In some cases of high-volume mail receivers,
>> they're not willing or able to devote enough resources to scan all
>> incoming mail in less time than a reasonable SMTP timeout, which is
>> what results in their broken behavior of dropping the message on the
>> floor, after-the-fact.
>>
>> Having worked on both sides of that coin in the ISP world, your best
>> hope of figuring out what's gone wrong is to:
>> a) ensure you're doing everything "right"
>> 0) setup DKIM for your apps-for-domain account:
>> http://support.google.com/a/bin/answer.py?hl=en&answer=174124
>> 1) send mail to an account you control, carefully inspect the
>> headers of the message you receive, post the headers somewhere like
>> TriLUG and ask someone else to look at it too
>> b) work with a user of the ISP in question to escalate through their
>> support chain (you'll have much better luck having a paying subscriber
>> initiate the conversation with tech support).
>> 0) coordinate with the user in real time, and send them a message
>> 1) give it at least half an hour, just to be on the safe side
>> 2) double-check that they haven't received it, in their inbox, spam
>> folder, trash, etc.
>> 3) have the user contact their ISP, and ask them about the message
>> they didn't receive. Have the following details about the missing
>> message ready:
>> i.) sender's email address
>> ii.) timestamp of the sent message
>> iii.) subject of the message
>> iv.) In a perfect world, you'd also want to have the name and IP
>> of the mail server that sent the message, and the name and IP of the
>> mail server that received the message, but you won't be able to get
>> that because you can't readily get it from your hosting provider.
>>
>> Ideally, when the user comes to tech support with that specific a
>> request, of a message that should have been delivered in the last few
>> hours, they should be able to escalate it up the chain to someone who
>> can inspect the mail system and logs and figure out where your message
>> went. They may say that it simply hasn't reached their system yet,
>> which would leave open the possibility that it was lost in the bowels
>> of Google Apps somewhere. Yes, that's a possibility, but speaking
>> from personal experience it's not a particularly likely one.
>>
>> Best of luck in troubleshooting your delivery problem. Let us know how it goes!
>> Aaron S. Joyner
>>
>> On Fri, Feb 8, 2013 at 10:47 AM, James Jones <jc.jones at tuftux.com> wrote:
>>> Since I am a Time-Warner customer, hopefully someone in their
>>> organization can help me.
>>>
>>> jcj
>>>
>>> On Fri, Feb 8, 2013 at 10:37 AM, Alan Porter <porter at trilug.org> wrote:
>>>>
>>>>> Are you saying that Google should have some response ( other than
>>>>> message received ) from nc.rr.com even if it gets swallowed up in rr's
>>>>> spam filter?
>>>>
>>>>
>>>> I suppose if RR is accepting it and then trashing it, there's nothing the
>>>> sender can do to know what's happening.
>>>>
>>>>
>>>>
>>>>> Since I don't get any bounce messages, I would assume all that Goog
>>>>> gets from nc.rr.com is "message received". Am I wrong?
>>>>
>>>>
>>>> I don't know how the Goog handles delivery errors. But your assumption does
>>>> makes sense.
>>>>
>>>>
>>>> --
>>>> # Alan Porter
>>>>
>>>>
>>>>
>>>> --
>>>> This message was sent to: jc jones <jc.jones at tuftux.com>
>>>> To unsubscribe, send a blank message to trilug-leave at trilug.org from that
>>>> address.
>>>> TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
>>>> Unsubscribe or edit options on the web :
>>>> http://www.trilug.org/mailman/options/trilug/jc.jones%40tuftux.com
>>>> TriLUG FAQ : http://www.trilug.org/wiki/Frequently_Asked_Questions
>>>
>>>
>>>
>>> --
>>> Jc Jones
>>> Blogs -
>>> http://www.wendellgeek.com/weblog/
>>> http://www.wendellgeek.com/kixtech/
>>>
>>> webmaster for:
>>> http://www.cottonseedchronicle.com
>>> http://www.trailblazersofnc.com
>>> http://www.steelmagnoliasgardenclub.org
>>> http://www.wendellgeek.com
>>> http://classof1955.org
>>> http://www.tuftux.com
>>> http://www.therealpatpatterson.com
>>> http://jonesjc.freeshell.org
>>> http://www.trilug.org/~jonesjc
>>> --
>>> This message was sent to: Aaron S. Joyner <aaron at joyner.ws>
>>> To unsubscribe, send a blank message to trilug-leave at trilug.org from that address.
>>> TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
>>> Unsubscribe or edit options on the web : http://www.trilug.org/mailman/options/trilug/aaron%40joyner.ws
>>> TriLUG FAQ : http://www.trilug.org/wiki/Frequently_Asked_Questions
>> --
>> This message was sent to: jc jones <jc.jones at tuftux.com>
>> To unsubscribe, send a blank message to trilug-leave at trilug.org from that address.
>> TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
>> Unsubscribe or edit options on the web : http://www.trilug.org/mailman/options/trilug/jc.jones%40tuftux.com
>> TriLUG FAQ : http://www.trilug.org/wiki/Frequently_Asked_Questions
>
>
>
> --
> Jc Jones
> Blogs -
> http://www.wendellgeek.com/weblog/
> http://www.wendellgeek.com/kixtech/
>
> webmaster for:
> http://www.cottonseedchronicle.com
> http://www.trailblazersofnc.com
> http://www.steelmagnoliasgardenclub.org
> http://www.wendellgeek.com
> http://classof1955.org
> http://www.tuftux.com
> http://www.therealpatpatterson.com
> http://jonesjc.freeshell.org
> http://www.trilug.org/~jonesjc
> --
> This message was sent to: Aaron S. Joyner <aaron at joyner.ws>
> To unsubscribe, send a blank message to trilug-leave at trilug.org from that address.
> TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
> Unsubscribe or edit options on the web : http://www.trilug.org/mailman/options/trilug/aaron%40joyner.ws
> TriLUG FAQ : http://www.trilug.org/wiki/Frequently_Asked_Questions
More information about the TriLUG
mailing list