Mailing List Archive

Daryl Odnert wrote:

> Section 7.1 of the SPF specification makes reference to the "current
> timestamp in UTC epoch seconds notation." Can somebody please provide a
> reference to where this notation is defined? I'd like to request that the
> SPF spec be updated to provide the reference too.

`man 2 time` refers to POSIX.1 documentation for this information. See
the manpage for details.

Cheers,

Jonathan Steinert

P.S. Windows users will likely need to dig through MSDN for a definition
of the time() C function... or search on the web for a public copy of th
e manpage.

>
> Thanks,
> Daryl Odnert
> Tumbleweed Communications
> Redwood City, California
>
>
>
> -------
> To unsubscribe, change your address, or temporarily deactivate your subscription,
> please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
>

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Daryl Odnert wrote:

> Section 7.1 of the SPF specification makes reference to the "current
> timestamp in UTC epoch seconds notation." Can somebody please provide
> a reference to where this notation is defined? I'd like to request
> that the SPF spec be updated to provide the reference too.

The textual form of the number of seconds since 1970 UTC, as described
by the "time" function conforming to IEEE Std 1003.1-2001 (``POSIX.1'').

--
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Postal Engine -- http://www.postalengine.com/
// Ecelerity: fastest MTA on Earth

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Theo Schlossnagle wrote:

> Daryl Odnert wrote:
>
>> Section 7.1 of the SPF specification makes reference to the "current
>> timestamp in UTC epoch seconds notation." Can somebody please
>> provide a reference to where this notation is defined? I'd like to
>> request that the SPF spec be updated to provide the reference too.
>
>
> The textual form of the number of seconds since 1970 UTC, as described
> by the "time" function conforming to IEEE Std 1003.1-2001 (``POSIX.1'').
>
(oh yeah... base 10)

--
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Postal Engine -- http://www.postalengine.com/
// Ecelerity: fastest MTA on Earth

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

I just printed out the return value of time() in decimal...

So '%{t}' would expand to '1081376746'


On Wednesday, April 7, 2004, at 06:01 PM, Daryl Odnert wrote:

> Section 7.1 of the SPF specification makes reference to the "current
> timestamp in UTC epoch seconds notation." Can somebody please provide
> a reference to where this notation is defined?  I'd like to request
> that the SPF spec be updated to provide the reference too.
>  
> Thanks,
> Daryl Odnert
> Tumbleweed Communications
> Redwood City, California
>  
>  
>
>
>
<image.tiff>
>
> To unsubscribe, change your address, or temporarily deactivate your
> subscription, please go to
> http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

In <7382FCA44E27D411BD4A00508BD68F950AE31013@pigeon.tumbleweed.com> "Daryl Odnert" <daryl.odnert@tumbleweed.com> writes:

> Section 7.1 of the SPF specification makes reference to the "current
> timestamp in UTC epoch seconds notation." Can somebody please provide a
> reference to where this notation is defined? I'd like to request that the
> SPF spec be updated to provide the reference too.


Others have answered your question, but I figure I might add this
comment.

libspf-alt allows the %{t} macro-variable *ONLY* in SPF explanation
records. It can not be used in mechanisms. Allowing %{t} in
mechanisms makes it much easier for malicious domain owners to create
DoS attacks on innocent third parties. If domain owners want to know
what time the mechanism was executed, they can check their DNS logs.
If they want to make sure that each DNS lookup is unique and not
cached, they can set the TTL of the RR to zero.


This is contrary to the SPF spec, but I believe that security issues
override conformance to the spec.


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

On Wed, Apr 07, 2004 at 05:29:42PM -0500, wayne wrote:
|
| libspf-alt allows the %{t} macro-variable *ONLY* in SPF explanation
| records. It can not be used in mechanisms. Allowing %{t} in
| mechanisms makes it much easier for malicious domain owners to create
| DoS attacks on innocent third parties. If domain owners want to know
| what time the mechanism was executed, they can check their DNS logs.
| If they want to make sure that each DNS lookup is unique and not
| cached, they can set the TTL of the RR to zero.
|
| This is contrary to the SPF spec, but I believe that security issues
| override conformance to the spec.
|

If other people agree with Wayne's position, we should change the spec.


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Thanks for the quick responses. In the interest of clarity, maybe instead
of saying:

t = current timestamp in UTC epoch seconds notation

the spec should say:

t = the current timestamp in UTC epoch seconds, expressed as a decimal
integer

Daryl Odnert
Tumbleweed Communications
Redwood City, California

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

I have a few links for those who might have interest in the issue:

Something about leap seconds: http://tycho.usno.navy.mil/leapsec.html

The GNU Libc date/time info says, that the time on GNU/Linux may include leap seconds in some cases:

http://docs.linux.cz/glibc-manual/libc_21.html

On my personal Linux system with Danish locale, time() doesn't do leap seconds, so I guess it's rare to see computer systems that do leap seconds. The difference between POSIX time and the actual number of seconds since january 1st, 1970 UTC, is about 14 seconds, and this small difference is usually handled by adjusting the time of the computer regularly. SPF doesn't rely on time being more precise than 1 second, so it's a non-issue.

The rest of my e-mail is copy & paste from somewhere on the net (use google if you want to find out where), but I don't think it's an important issue for SPF, since POSIX time is standardized until year 2038, and after that they will probably have fixed the problem described:

IEEE Std 1003.1-1996 contains an error in section 2.2.2.113 which defines
the term "seconds since the Epoch". The error is that the expression:

tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
(tm_year-70)*31536000 + ((tm_year-69)/4)*86400

does not correctly account for leap years. It adds one day for every
four years, thus disregarding the rule that years divisible by 100 are
only leap years if also divisible by 400.

The expression produces incorrect values for years 2101 onwards, and
so the error could perhaps be called a "Year 2101 bug". Of course,
this does not affect implementations with a (signed) 32-bit time_t,
which can only represent years up to 2038, and this probably explains
why the necessary extra parts of the expression were omitted in the
original 1988 standard.

Lars.


-----Oprindelig meddelelse-----
Fra: owner-spf-devel@v2.listbox.com på vegne af Theo Schlossnagle
Sendt: to 08-04-2004 00:08
Til: spf-devel@v2.listbox.com
Emne: Re: [spf-devel] UTC epoch seconds notation

Daryl Odnert wrote:
> Section 7.1 of the SPF specification makes reference to the "current
> timestamp in UTC epoch seconds notation." Can somebody please provide
> a reference to where this notation is defined? I'd like to request
> that the SPF spec be updated to provide the reference too.

The textual form of the number of seconds since 1970 UTC, as described
by the "time" function conforming to IEEE Std 1003.1-2001 (``POSIX.1'').

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

I think that "UTC epoch seconds notation" is very bad, because that includes leap seconds and is very complicated for people to handle:

http://hpiers.obspm.fr/eop-pc/earthor/utc/leapsecond.html

I would suggest:

t = the current timestamp in POSIX epoch seconds, expressed as a decimal integer

This would make it possible to use Linux/Unix/Windows API functions to get that number easily. It would also make the time at midnight get a nice 0-digit at the end, which is something most people can relate to.

Lars.


-----Oprindelig meddelelse-----
Fra: owner-spf-devel@v2.listbox.com på vegne af Daryl Odnert
Sendt: to 08-04-2004 00:39
Til: 'spf-devel@v2.listbox.com'
Emne: RE: [spf-devel] UTC epoch seconds notation

Thanks for the quick responses. In the interest of clarity, maybe instead
of saying:

t = current timestamp in UTC epoch seconds notation

the spec should say:

t = the current timestamp in UTC epoch seconds, expressed as a decimal
integer

Daryl Odnert
Tumbleweed Communications
Redwood City, California

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com



-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

In <8044674@pamho.net> "Roger Moser" <Roger.Moser@pamho.net> writes:

> Wayne wrote:
>
>> libspf-alt allows the %{t} macro-variable *ONLY* in SPF explanation
>> records.
>
> But for explanation records shouldn't the %{t} macro variable produce a
> human-readable string?

Well, maybe, but that creates a lot of i18n problems, timezone
ambiguities, etc.


> What is actually the use of the %{t} macro variable?

The idea is that you can create an expalantion string that creates a
URL and the %{t} value would be passed as a CGI parapmeter. The CGI
script would then do the appropriate conversion of seconds since
epoch. The CGI script might also use the time to help find the
appropriate message in various logs/databases and give additional
diagnostics that couldn't be done with out a time value.

> BTW Wayne: snprintf( time_buf, sizeof( time_buf ), "%ld", time(0))
> works only if time_t is a 'long int'. Isn't it?

Yeah, you are right, but all the world is a VAX. No, wait, all the
world is a Sun. Uh, all the world is a x86 running Linux?


You are right, it is not portable and needs to be fixed. However,
since I've never seen an SPF record that actually uses the %{t}
macro-var and therefore it has been low priority to fix.


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

On Thu, 2004-04-08 at 17:05, wayne wrote:

> >> libspf-alt allows the %{t} macro-variable *ONLY* in SPF explanation
> >> records.
> >
> > But for explanation records shouldn't the %{t} macro variable produce a
> > human-readable string?
>
> Well, maybe, but that creates a lot of i18n problems, timezone
> ambiguities, etc.

I think that there may be some i18n agnostic and still human readable
formats. E.g.:

2004-04-08 18:27:00 +0400

(not that I am suggesting to use it...)

> > BTW Wayne: snprintf( time_buf, sizeof( time_buf ), "%ld", time(0))
> > works only if time_t is a 'long int'. Isn't it?
>
> Yeah, you are right, but all the world is a VAX. No, wait, all the
> world is a Sun. Uh, all the world is a x86 running Linux?

No, the whole world is soon going to be x86-64 running Linux ;-)
As for me, I usually do

printf("%ld", (long)time((time_t*)0);

though it still may suffer from Y2038 bug.

Eugene

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

> I think that there may be some i18n agnostic and still human readable
> formats. E.g.:
>
> 2004-04-08 18:27:00 +0400
>
> (not that I am suggesting to use it...)
>
ISO 8601 date/times, used by RDF, others:

2004-04-08T18:27:00Z

The 'T' separates date from time, the 'Z' indicates the time zone, in
this case UTC. ISO-8601 includes extra syntax for more timezones,
which perhaps should be outlawed for SPF.

A problem: the %{t2r} type syntax wouldn't work quite right, if
additional processing is expected on time strings, given that the 'T'
couldn't be used as a separator character.
An alternate format could be:

2004.04.08.18.27.00
---
I'm definitely for changing the format, and adopting the libspf-alt
technique of only allowing it in exp macros. I don't think there's a
big implementation issue (just call gmtime, then strftime), and I don't
think there's a big backwards-compatibility issue... CGI scripts might
have to parse both '1081435467' as well as '2004-04-08T14:44:27Z'

Cheers

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

In <1081434447.3038.36.camel@ariel.sovam.com> Eugene Crosser <crosser@rol.ru> writes:

> On Thu, 2004-04-08 at 17:05, wayne wrote:
>
>> >> libspf-alt allows the %{t} macro-variable *ONLY* in SPF explanation
>> >> records.
>> >
>> > But for explanation records shouldn't the %{t} macro variable produce a
>> > human-readable string?
>>
>> Well, maybe, but that creates a lot of i18n problems, timezone
>> ambiguities, etc.
>
> I think that there may be some i18n agnostic and still human readable
> formats. E.g.:
>
> 2004-04-08 18:27:00 +0400

Is that month-day or day-month? And what is this hour of "18" all
about? And the +0400 is *VERY* confusing, and... </devil's adocate mode>


>> > BTW Wayne: snprintf( time_buf, sizeof( time_buf ), "%ld", time(0))
>> > works only if time_t is a 'long int'. Isn't it?
>>
>> Yeah, you are right, but all the world is a VAX. No, wait, all the
>> world is a Sun. Uh, all the world is a x86 running Linux?
>
> No, the whole world is soon going to be x86-64 running Linux ;-)
> As for me, I usually do
>
> printf("%ld", (long)time((time_t*)0);

Well, I chose "%ld", (long int)time( NULL )

I hate casts though...


> though it still may suffer from Y2038 bug.

Anything that doesn't use a 64-bit time_t by then will probably just
switch to an unsigned 32-bit time_t instead of a signed time_t. By
then, the need to represent dates before 1970 in time_t format will
be almost zero.

-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Wayne wrote:

> libspf-alt allows the %{t} macro-variable *ONLY* in SPF explanation
> records.

But for explanation records shouldn't the %{t} macro variable produce a
human-readable string?

What is actually the use of the %{t} macro variable?

ys Ramakanta dasa

BTW Wayne: snprintf( time_buf, sizeof( time_buf ), "%ld", time(0))
works only if time_t is a 'long int'. Isn't it?

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Theo wrote:

> The textual form of the number of seconds since 1970 UTC, as described
> by the "time" function conforming to IEEE Std 1003.1-2001 (``POSIX.1'').

Why referring to standards that one has to look up? Why not just write:

The decimal textual notation (without leading zeros) of the number of
seconds elapsed since 00:00:00 UTC, January 1, 1970.

Roger

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com