Re: About date spoofing

2 msg	MASQUERADING FROM BUT NOT TO
3 msg	Probably not a Postfix problem...?
3 msg	Quick question with user/virtual aliases.
4 msg	Sending healty batch emails
5 msg	use of relayhost, relaydomain?
6 msg	naming the mail server
1 msg	Re: statistics by client ip address - SOLVED
3 msg	question marks on permissions/owner
2 msg	Configuring Postfix to Receive Mail from Outloo...
3 msg	tcp_table and propose for new lookup table 'pip...

About date spoofing
\ AlxFrag (14 Mar 2008)
. \ Don Piven (14 Mar 2008)
. \ (Wietse Venema) (14 Mar 2008)
. \ Ralf Hildebrandt (14 Mar 2008)
. \ Eddy Beliveau (14 Mar 2008)
. . \ Noel Jones (14 Mar 2008)
. \ Eddy Beliveau (14 Mar 2008)
. . \ mouss (14 Mar 2008)
. \ mouss (14 Mar 2008)
. \ Eddy Beliveau (14 Mar 2008)
. . \ mouss (14 Mar 2008)
. . \ Mark Martinec (15 Mar 2008)

3 msg	Overriding DNS lookups for a specific domain
2 msg	redirecting a single email address/alias (not a...
1 msg	statistics by client ip address
2 msg	sender+ip restrictions
14 msg	postfix-2.5 RPMs available
1 msg	Setting up Postfix on Solaris 10
8 msg	Yet another virtual domain problem - do not lis...
2 msg	getting a user permissions error
2 msg	551 mail refused

Subject:	Re: About date spoofing
Group:	Postfix-users
From:	Mark Martinec
Date:	15 Mar 2008

Do not get carried away too far with this business of replacing
a Date header field - it is breaking the semantics of this field
as stated in RFC 2822, and it is solving the wrong problem.

If a time of *reception* matters, look at the date/time of reception
in the Received header field as supplied by your perimeter MX
(and make sure this MX MTA has its clock under control of NTP).

If a time of a mail *composition/mail-submission* matters, your only
choice is to trust whatever data is supplied by the author, unless
a submitter is required to provide a certified timestamp on a
document/message from some trustworthy timestamping service.

Mark