RejectedSoftware Forums

Am 15.02.2013 09:50, schrieb Nick Sabalausky:

When using the SMTP module, currently the Date header needs to be
filled out manually (it seems that some SMTP servers will auto-fill
it if missing, but others apparently don't).

That wouldn't be too bad except, as far as I can tell, vibe.d doesn't
have a function to convert a SysTime or other date to the appropriate
format. And I know phobos doesn't have one (and likely won't anytime
soon, judging by
https://github.com/D-Programming-Language/phobos/pull/1140).

I'd be glad to donate my function for it (maybe with proper validation
added) with a pull request, but I thought I'd ask where you think it
should go. vibe.utils.string? Some new utils module? The regular SMTP
module itself?

There already is vibe.inet.message.toRFC822DateTimeString - I'm not
sure if a better place is possible, but since it's part of the internet
message format definition, it seems like the most logical place for it.

The names of these functions might be better off as
toInetDateTimeString or similar, but I wasn't sure if it wouldn't be
necessary to have implementations against different RFCs for the same
function at some point.

Also, I was thinking it would be nice if the SMTP module could fill the
Date header automatically if it's missing...But then it occurred to me
the problem with that is "What if someone wants/needs full control
over the entire message, perhaps for testing a server?" What are your
thoughts?

I think that may be a good idea. A boolean field could be added to
SmtpClientSettings to disable that behavior.

Or - maybe even better - the Mail class could get a default
constructor (+maybe a constructor that takes values for all the basic
fields) that pre-fills it and if needed, they can be removed from
Mail.headers manually.

Am 15.02.2013 12:06, schrieb Nick Sabalausky:

On Fri, 15 Feb 2013 10:14:20 +0100
Sönke Ludwig sludwig@rejectedsoftware.com wrote:

There already is vibe.inet.message.toRFC822DateTimeString - I'm not

Ahh, I totally missed that! Looks like a very fast implementation, too.

Technically though (and completely "FWIW"), using "GMT" instead of
"+0000" is considered an obsolete form according to RFC 5322.

Right, I remember to have stumbled over this before, but obviously I
haven't taken any action on it. So this would now actually possibly be
the first case where it would make sense to support both.

Not sure how many implementations actually rely on the old standard
though... and also I can't imagine a parser that accepts +0100, but not
+0000. So maybe it makes sense to just eliminate the if statement...