[TriLUG] Email Problems

Fri Feb 8 11:41:13 EST 2013

Maybe I missed it earlier in the thread, but are you absolutely sure the email didn't end up in the SPAM or TRASH folder?

Thanks,

-----------------------------
Ron Kelley
rkelleyrtp at gmail.com

On Feb 8, 2013, at 11:29 AM, Aaron Joyner 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: Ron Kelley <rkelleyrtp at gmail.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/rkelleyrtp%40gmail.com
> TriLUG FAQ          : http://www.trilug.org/wiki/Frequently_Asked_Questions