Disappearing email - could be OT

[Steve Campbell]

I read that, and didn't see a lot on the system wide file. A lot of 
references to the $HOME one though.

Anyway, what might cause this one particular sender to have such a 
problem? As I mentioned, I receive emails from other senders of their 
domain through the same sending server (based on IP address). I hate to 
say this, because it usually bite the one who says it, but nothing has 
changed. It appears to have started happening for this sender about 3 
months ago. I love it when they wait that long to alert me.

Thanks for all the ideas so far.

steve
On 2/11/2013 4:53 PM, Alex Neuman wrote:
> There's a system-wide procmailrc file, and there are individual 
> .procmailrc files for different users. Check the man page for details.
>
> On Mon, Feb 11, 2013 at 3:33 PM, Steve Campbell <campbell at cnpapers.com 
> <mailto:campbell at cnpapers.com>> wrote:
>
>     Nope. Different senders from the same domain come through fine. I
>     can't say whether different senders to the same recipient varies any.
>
>     We actually receive emails from the same server (with the same IP)
>     that go through normally from other addresses of that domain.
>
>     Which procmailrc file are you referring to? I don't have any
>     installed under any user.
>
>     Thanks, Alex
>
>     steve
>
>
>     On 2/11/2013 2:36 PM, Alex Neuman wrote:
>>     Could be a .procmailrc issue. Does it happen to *all* e-mails,
>>     regardless of recipient?
>>
>>     On Mon, Feb 11, 2013 at 1:06 PM, Steve Campbell
>>     <campbell at cnpapers.com <mailto:campbell at cnpapers.com>> wrote:
>>
>>         I'm seeing a problem from a couple of my servers. I have a
>>         primary
>>         server for one of our domains, but I see emails coming through a
>>         secondary server for this domain. The email that gets sent
>>         through the
>>         secondary is relayed to the primary just fine.
>>
>>         The problem is that the primary accepts the email and then
>>         disappears. I
>>         see a line in my sendmail logs like the following:
>>
>>         On the secondary:
>>         sendmail[17339]: r1BGGT8J017339: from=<xxxxxx at yyyyy.
>>         com>, size=0, class=0, nrcpts=1, proto=ESMTP, daemon=MTA,
>>         relay=173-219-91-250.s
>>         ta.suddenlink.net <http://ta.suddenlink.net> [173.219.91.250]
>>         (may be forged)
>>
>>         On the primary (relayed from the secondary above):
>>         sendmail[31249]: r1BGGZCZ031249: from=<debbie at kcprc.com
>>         <mailto:debbie at kcprc.com>>, size=0,
>>         class=0, nrcpts=1, proto=SMTP, daemon=MTA,
>>         relay=mailserver1.cnpapers.net
>>         <http://mailserver1.cnpapers.net> [10.0.0.103]
>>
>>         The logs above are for the same message. This is the only
>>         entries I see
>>         for this email in both logs. The email isn't delivered,
>>         logged through
>>         Mailscanner, and doesn't exist in the mqueue or mqueue.in
>>         <http://mqueue.in> directory.
>>
>>         Has anyone seen this type of problem before? How did it get
>>         solved? Any
>>         reason to believe there's a problem in  the processing
>>         database and how
>>         do I discover this?
>>
>>         thanks
>>
>>         steve campbell
>>
>>         Thanks for any
>>         --
>>         MailScanner mailing list
>>         mailscanner at lists.mailscanner.info
>>         <mailto:mailscanner at lists.mailscanner.info>
>>         http://lists.mailscanner.info/mailman/listinfo/mailscanner
>>
>>         Before posting, read http://wiki.mailscanner.info/posting
>>
>>         Support MailScanner development - buy the book off the website!
>>
>>
>>
>>
>>     -- 
>>
>>     --
>>
>>     Alex Neuman van der Hans
>>     Reliant Technologies / Vida Digital
>>     http://vidadigital.com.pa/
>>
>>     +507-6781-9505 <tel:%2B507-6781-9505>
>>     +507-832-6725 <tel:%2B507-832-6725>
>>     +1-440-253-9789 <tel:%2B1-440-253-9789> (USA)
>>
>>     Follow @AlexNeuman on Twitter
>>     http://facebook.com/vidadigital
>>
>>
>>     -- So-called "legal disclaimers" are not legally binding, so
>>     don't bother. A cute graphic saying "save the planet, don't print
>>     this" can potentially create more CO2, not less, so don't bother
>>     either.
>>
>>
>
>
>     --
>     MailScanner mailing list
>     mailscanner at lists.mailscanner.info
>     <mailto:mailscanner at lists.mailscanner.info>
>     http://lists.mailscanner.info/mailman/listinfo/mailscanner
>
>     Before posting, read http://wiki.mailscanner.info/posting
>
>     Support MailScanner development - buy the book off the website!
>
>
>
>
> -- 
>
> --
>
> Alex Neuman van der Hans
> Reliant Technologies / Vida Digital
> http://vidadigital.com.pa/
>
> +507-6781-9505
> +507-832-6725
> +1-440-253-9789 (USA)
>
> Follow @AlexNeuman on Twitter
> http://facebook.com/vidadigital
>
>
> -- So-called "legal disclaimers" are not legally binding, so don't 
> bother. A cute graphic saying "save the planet, don't print this" can 
> potentially create more CO2, not less, so don't bother either.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mailscanner.info/pipermail/mailscanner/attachments/20130212/1a633517/attachment.html