Re: env_from set to <> after Z action

Kristin Hubner wrote:
> What we'd really like is debugging -- but as a lighter weight way to get
> at least
> some additional information if it happens again, how about setting some
> more logging
> options.  I'm thinking particularly of LOG_PROCESS and LOG_FILENAME, but
> maybe
> LOG_FILTER too.  Then if it does happen again, please open a case and
> send support
> an entire, unsanitized chunk of mail.log* around the occurrence -- your
> comment that
> it only happened during a time of heavy spam load makes me wonder if it
> was just one
> thread that seemed to "lose" the envelope From (and if so, what were
> other threads in
> that process doing around that same time), or multiple threads?

OK, I'll just wait for another one of our users to send their password
to a phisher again.  Statistically, that should be any day now...  :-)


> Do you use the FROM_ACCESS mapping table?  If so, what's in it?

No, not on our outgoing MTAs.

Jesse


> 
> Regards,
> 
> Kristin
> 
> On Jun 24, 2008, at 1:43 PM, Jesse Thompson wrote:
> 
>> Ned Freed wrote:
>>> I'm more suspicious that the message didn't have an envelope from to
>>> begin with.
>>
>> No, it didn't.  Here are the [sanitized] logs:
>>
>> here is the log of the normal enqueue:
>>
>> 21-Jun-2008 06:11:11.92 tcp_intranet avs          EE 6
>> LOCALUSER-F1FbuMAf82JPjaDqJt1ogQ@xxxxxxxxxxxxxxxx 
>> rfc822;REMOTEUSER-RKDGOo/4GHQ9E24vwMF+KA@xxxxxxxxxxxxxxxx
>> REMOTEUSER-RKDGOo/4GHQ9E24vwMF+KA@xxxxxxxxxxxxxxxx 
>> <e53191252b2e.485cefe0-F1FbuMAf82JPjaDqJt1ogQ@xxxxxxxxxxxxxxxx> mailsrv
>> LOCAL.DOMAIN (STORE.LOCAL.DOMAIN [1.2.3.4])
>>
>> 21-Jun-2008 06:11:14.01 avs          tcp_local    E 7
>> LOCALUSER-F1FbuMAf82JPjaDqJt1ogQ@xxxxxxxxxxxxxxxx 
>> rfc822;REMOTEUSER-RKDGOo/4GHQ9E24vwMF+KA@xxxxxxxxxxxxxxxx
>> REMOTEUSER-RKDGOo/4GHQ9E24vwMF+KA@xxxxxxxxxxxxxxxx 
>> <e53191252b2e.485cefe0-F1FbuMAf82JPjaDqJt1ogQ@xxxxxxxxxxxxxxxx> mailsrv
>> avs-daemon.MTA.LOCAL.DOMAIN
>>
>> 21-Jun-2008 06:11:14.11 avs                       D 6
>> LOCALUSER-F1FbuMAf82JPjaDqJt1ogQ@xxxxxxxxxxxxxxxx 
>> rfc822;REMOTEUSER-RKDGOo/4GHQ9E24vwMF+KA@xxxxxxxxxxxxxxxx
>> REMOTEUSER-RKDGOo/4GHQ9E24vwMF+KA@xxxxxxxxxxxxxxxx 
>> <e53191252b2e.485cefe0-F1FbuMAf82JPjaDqJt1ogQ@xxxxxxxxxxxxxxxx> mailsrv
>>
>> here's the enqueue of the rewritten form of the message:
>>
>> 21-Jun-2008 06:11:16.09 avs          tcp_local    E 7
>> rfc822;REMOTEUSER-RKDGOo/4GHQ9E24vwMF+KA@xxxxxxxxxxxxxxxx 
>> REMOTEUSER-RKDGOo/4GHQ9E24vwMF+KA@xxxxxxxxxxxxxxxx
>> <e53191252b2e.485cefe0-F1FbuMAf82JPjaDqJt1ogQ@xxxxxxxxxxxxxxxx> mailsrv 
>> avs-daemon.MTA.LOCAL.DOMAIN
>>
>> here is the Z rejection of the original form of the message:
>>
>> 21-Jun-2008 06:11:16.09 tcp_local                 ZE 7
>> LOCALUSER-F1FbuMAf82JPjaDqJt1ogQ@xxxxxxxxxxxxxxxx 
>> rfc822;REMOTEUSER-RKDGOo/4GHQ9E24vwMF+KA@xxxxxxxxxxxxxxxx
>> REMOTEUSER-RKDGOo/4GHQ9E24vwMF+KA@xxxxxxxxxxxxxxxx 
>> <e53191252b2e.485cefe0-F1FbuMAf82JPjaDqJt1ogQ@xxxxxxxxxxxxxxxx> mailsrv
>> REMOTE.DOMAIN dns;REMOTE.DOMAIN (TCP|2.3.4.5|59912|3.4.5.6|25)
>> (REMOTE.SERVER ESMTP **************************) smtp;552
>> <REMOTEUSER-RKDGOo/4GHQ9E24vwMF+KA@xxxxxxxxxxxxxxxx>: Recipient address 
>> rejected: 5.2.2 Over quota
>>
>> the Q entry repeats indefinitely...
>>
>> 21-Jun-2008 06:11:16.22 tcp_local                 QE 6
>> rfc822;REMOTEUSER-RKDGOo/4GHQ9E24vwMF+KA@xxxxxxxxxxxxxxxx 
>> REMOTEUSER-RKDGOo/4GHQ9E24vwMF+KA@xxxxxxxxxxxxxxxx
>> <e53191252b2e.485cefe0-F1FbuMAf82JPjaDqJt1ogQ@xxxxxxxxxxxxxxxx> mailsrv  
>> dns;REMOTE.DOMAIN
>> (TCP|2.3.4.5|59912|3.4.5.6|25) (REMOTE.SERVER ESMTP
>> **************************) smtp;552 
>> <REMOTEUSER-RKDGOo/4GHQ9E24vwMF+KA@xxxxxxxxxxxxxxxx>:
>> Recipient address rejected: 5.2.2 Over quota 
>> REMOTEUSER-RKDGOo/4GHQ9E24vwMF+KA@xxxxxxxxxxxxxxxx:
>> smtp;552 <REMOTEUSER-RKDGOo/4GHQ9E24vwMF+KA@xxxxxxxxxxxxxxxx>: R
>>
>>
>>
>>
>>> But the only way to figure out what's happening is to get some
>>> debugging going.
>>
>> I can't simulate it.  I tried using the same recipient address, using
>> the same production server environment.
>>
>> This happened when one of our local user accounts was compromised by a
>> spammer and used to send thousands of messages out via our webmail
>> interface.  The vast majority of the queued messages had the env_from
>> set to the original address.  Around 100 had the env_from set to <>.
>>
>> Jesse
>>
>>
>>
>>>
>>>                 Ned
>>>
>>
>> -- 
>>   Jesse Thompson
>>   Email/IM: jesse.thompson-gHeKliYv1294piUD7e9S/g@xxxxxxxxxxxxxxxx
> 

-- 
  Jesse Thompson
  Email/IM: jesse.thompson-gHeKliYv1294piUD7e9S/g@xxxxxxxxxxxxxxxx

smime.p7s
Description: S/MIME Cryptographic Signature