bugSpamAssassin Milter Plugin - Bugs: bug #29550, Generated Received header has...

 
 

bug #29550: Generated Received header has incorrect Date

Submitter:  Stuart Schneider <helpdesk>
Submitted:  Wed 14 Apr 2010 04:32:11 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  In Progress
Privacy:  Public Assigned to:  gdt
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 01 Aug 2020 07:01:40 PM UTC, comment #7: 

There has been list traffic about this and it seems to be a config issue, but it remains to check if the spamass-milter docs are correct.

Greg Troxel <gdt>
Group Member
Fri 21 May 2010 12:00:57 PM UTC, comment #6: 

The `b' macro is supposed to be updated by sendmail whenever a new SMTP connection starts or when it does a queue run.

I'm struggling to conceive how it could be that far out. Perhaps it would be better, at least in your case, to avoid the use of the `b' macro altogether and just use localtime() instead?

Paul Howarth <pghmcfc>
Fri 21 May 2010 03:22:28 AM UTC, comment #5: 

I've been able to log the value of the "b" macro and localtime from a milter.

A quick summary of the 41k+ total messages logged from two different servers: 2800+ (almost 7%) have the value of the b macro 2+ days prior to localtime (the difference is at least 2.1 days to as much as 5.8 days).  The difference between the b macro and localtime for the remainder (93%) of the messages is less than 230 seconds.

Doing a spot-check of the final Received header generated by sendmail (after the emails have been forwarded on to an internal Exchange server) shows that the date is within a couple seconds of localtime.

I am unable to determine any pattern for why the b macro is so far off.  From a spot-check, the majority of the messages with the largest difference are all valid (ham) emails.

I can potentially upload a CSV file showing the dates and ident if it would be helpful.  Any suggestions on how to further track this problem down?  It almost appears to be a bug within sendmail's milter system, but that is beyond what I would be able to troubleshoot.

Stuart Schneider <helpdesk>
Wed 05 May 2010 10:45:30 AM UTC, comment #4: 

The code in spamass-milter is basically this:


const char *macro_b;
char date[32];

/* RFC 822 date. */
macro_b = smfi_getsymval(ctx, "b");
if (!macro_b)
{
        time_t tval;
        time(&tval);
        strftime(date, sizeof(date), "%a, %d %b %Y %H:%M:%S %z", localtime(&tval));
        macro_b = date;
}


So you want to check the state of the `b' macro and the value of localtime and see if either or both look suspicious.

Paul Howarth <pghmcfc>
Tue 20 Apr 2010 09:32:57 PM UTC, comment #3: 

That comment was from me - I've apparently rememberd the original account I had setup here.

Stuart Schneider <helpdesk>
Tue 20 Apr 2010 09:30:41 PM UTC, comment #2: 

Yes, this is in my sendmail.mc (which builds the sendmail.cf):

define(`confMILTER_MACROS_ENVRCPT',confMILTER_MACROS_ENVRCPT`, b, r, v, Z')dnl

That generates this in the sendmail.cf:

O Milter.macros.envrcpt={rcpt_mailer}, {rcpt_host}, {rcpt_addr}, b, r, v, Z


I have a few milters which I wrote some time ago that use the other macros.

Sendmail is sendmail-8.13.8-2.el5 - the most recent RPM version from the official CentOS repository.

I'll see if I can cobble together a milter to log the value of the b macro for each message.  Other than that - any suggestions for what additional information would be useful to collect?

Stuart <schneis>
Mon 19 Apr 2010 08:35:43 PM UTC, comment #1: 

Do you have the `b' macro included in confMILTER_MACROS_ENVRCPT? If so, the milter gets the date from sendmail via that macro, else it generates it from the local time on the machine.

Paul Howarth <pghmcfc>
Wed 14 Apr 2010 04:32:11 AM UTC, original submission:  

Had originally thought that this was a bug with SpamAssassin until testing finally showed that the date in the Received header by the milter is incorrect.

Full details are in the SA bug here:
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6296

Essentially, on some emails the date in the Received header that SpamAssassin sees is off by several days.

The version of spamass-milter is the most recent from RPMforge/DAG (spamass-milter-0.3.1-1.el5.rf).

Stuart Schneider <helpdesk>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gdt (Posted a comment)
  • -email is unavailable- added by schneis (Posted a comment)
  • -email is unavailable- added by pghmcfc (Posted a comment)
  • -email is unavailable- added by helpdesk (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-08-01 gdt StatusNone In Progress
        Assigned toNone gdt

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code