headers
Michael Haardt | 3 Jun 2008 12:25

Adding RFC 2822 date parsing code

Hello,

are there any objections against adding parse_date_time() to parse.c for
parsing RFC 2822 dates? I am still playing with how to use it best, but
the parsing code is already finished and may be useful to others as well.

One idea is to add an expansion variable that contains the difference
between Resent-Date:/Date: and the current time.  It shouldn't be far
in the future and not more than a couple days in the past.  Perhaps the
time in seconds since 1970 may be more useful - any opinions?

Michael

--

-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##
Permalink | Reply |
headers
Dave Evans | 3 Jun 2008 14:26
Picon
Favicon

Re: Adding RFC 2822 date parsing code

On Tue, Jun 03, 2008 at 12:25:34PM +0200, Michael Haardt wrote:
> Hello,
> 
> are there any objections against adding parse_date_time() to parse.c for
> parsing RFC 2822 dates? I am still playing with how to use it best, but
> the parsing code is already finished and may be useful to others as well.
> 
> One idea is to add an expansion variable that contains the difference
> between Resent-Date:/Date: and the current time.  It shouldn't be far
> in the future and not more than a couple days in the past.  Perhaps the
> time in seconds since 1970 may be more useful - any opinions?

I've found such a measure useful for spam filtering.  I implemented something
similar using ${perl.  I found that an incomplete parser (only looking for a
few commonly-used combinations of formats of the many that rfc2822 allows) was
good enough, for my use.  i.e. I never saw any non-spam email use particularly
exotic formats.

I would suggest that an absolute seconds-since-epoch would be more useful than
a difference-from-now value.

As for whether/how to implement this within Exim, though, I couldn't say :-/

-- 
Dave Evans
http://djce.org.uk/
http://djce.org.uk/pgpkey

--

--
(Continue reading)

Permalink | Reply |
headers
Michael Haardt | 4 Jun 2008 10:35

Re: Adding RFC 2822 date parsing code

> I've found such a measure useful for spam filtering.  I implemented something
> similar using ${perl.  I found that an incomplete parser (only looking for a
> few commonly-used combinations of formats of the many that rfc2822 allows) was
> good enough, for my use.  i.e. I never saw any non-spam email use particularly
> exotic formats.

Actually, date-time from RFC 2822 is not that complicated once you look
at the required obsoleted grammar parts.

Indeed some spammers use entirely wrong dates, but most don't.  I was
mostly looking into enhancing the formal quality of submissions, but
catching a few dumb spammers is a nice side effect.

> I would suggest that an absolute seconds-since-epoch would be more useful than
> a difference-from-now value.

Just curious: Why? It's no problem really, because you can subtract it
from $tod in ACLs, as you could add $tod to an age.  Which application
of an absolute value do you have in mind?

> As for whether/how to implement this within Exim, though, I couldn't say :-/

An implementation inside Exim is a vital part of being able to parse
"Received:" fields.  Any votes now? ;)

Michael

--

-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##
(Continue reading)

Permalink | Reply |
headers
Tony Finch | 4 Jun 2008 14:48
Picon
Favicon

Re: Adding RFC 2822 date parsing code

On Wed, 4 Jun 2008, Michael Haardt wrote:
>
> Indeed some spammers use entirely wrong dates, but most don't.  I was
> mostly looking into enhancing the formal quality of submissions, but
> catching a few dumb spammers is a nice side effect.

That sounds like it might be useful. I'm not convinced that Exim should
try to provide enough features that people can re-implement SpamAssassin
in the ACL language.

Tony.
-- 
f.anthony.n.finch  <dot <at> dotat.at>  http://dotat.at/
FITZROY: SOUTHWESTERLY VEERING NORTHWESTERLY 4 OR 5, OCCASIONALLY 6 AT FIRST.
ROUGH. RAIN THEN SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR AT FIRST.

--

-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##
Permalink | Reply |
headers
Michael Haardt | 4 Jun 2008 15:37

Re: Adding RFC 2822 date parsing code

> That sounds like it might be useful. I'm not convinced that Exim should
> try to provide enough features that people can re-implement SpamAssassin
> in the ACL language.

Ok, so I committed the patch to src/functions.h and src/parse.c.  The new
function parse_date_time() works like the other parse_* functions.
There is no reference of it yet, because it is not yet clear how it is
used best, but that part is easier and will follow another time.

I certainly felt better when I could send patches to Philip, because he
always looked at them closely.  I appreciate any feedback.

Michael

--

-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##
Permalink | Reply |
headers
Nigel Metheringham | 4 Jun 2008 14:55
Picon
Gravatar

Re: Adding RFC 2822 date parsing code


On 4 Jun 2008, at 13:48, Tony Finch wrote:

> I'm not convinced that Exim should
> try to provide enough features that people can re-implement  
> SpamAssassin
> in the ACL language.

Towers of Hanoi, anyone?

--
[ Nigel Metheringham             Nigel.Metheringham <at> InTechnology.com ]
[ - Comments in this message are my own and not ITO opinion/policy - ]

--

-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##
Permalink | Reply |

Gmane