Disappearing email - could be OT

[Steve Campbell]

I'm starting to see some clues now.

I received a few emails with very simple text from a sender of the 
domain. The header from the sender seems to be very basic, with no To: 
and Subject: header lines in the header. I'm guessing that an attachment 
would cause the zero size emails that are being sent, for some reason.

Hopefully, a request to their administrator will get things started 
towards solving this problem.

Thanks
steve
On 2/12/2013 8:02 AM, Steve Campbell wrote:
> 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/828f532f/attachment.html