[unisog] .edu's who use SpamCop?

Valdis.Kletnieks at vt.edu Valdis.Kletnieks at vt.edu
Tue Dec 23 03:52:18 GMT 2003


On Mon, 22 Dec 2003 08:54:08 GMT, Mike Meredith said:
> On Fri, 19 Dec 2003 11:05:33 -0500, Valdis.Kletnieks at vt.edu wrote:
> > OK, you got me there.  I'll see your Section 4.1.1.1 and raise you a
> > Section 4.1.4:
> > 
> >    However, the server MUST NOT refuse to accept a message for this
> 
> Yup. And what a dumb idea that was.
> 
> If you're not going to enforce a standard, why bother having one ?

OK... The reason it ended up that way is because 4.1.1.1 only makes the
requirement to send an address literal a SHOULD.  It's not a MUST because there
exist real cases where a host does literally NOT KNOW if it really has a valid
hostname at the moment (for instance, consider the case of my laptop doing
dynamic DNS updates, and it has sucessfully updated its A record and its PTR
record on the DNS server it contacted - but the TTL of the *PREVIOUS*
assignment hasn't run out on all our other 7 nameservers yet (yes, we have 5 NS
listed for vt.edu, plus another several internal-facing ones).  So unless I
actually go and ask ALL the NS if they've seen the update yet, there's a race
condition - I connect, update the DNS, send mail, the server at the other end
looks up my PTR, contacts an NS that hasn't seen the update yet....

There's a number of other corner cases (for instance, if I'm roaming and
there's a network outage that takes out my home site, it's possible that I can
reach your SMTP server, but you can't reach my DNS to verify things).

It's cases like that why it's a "MUST NOT refuse".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://www.dshield.org/pipermail/unisog/attachments/20031222/eeabb94b/attachment-0003.bin


More information about the unisog mailing list