ietf-mxcomp
[Top] [All Lists]

RE: Unified SPF: block versus factored records for HELO and MTAMA ark scopes

2004-06-24 21:30:06


Most Unix MTAs including sendmail, exim, qmail and (I believe) postfix
fork off a process per SMTP session which exits at the end of the
session.  In this case, any effort beyond that to validate the single
IP used in the session is wasted, and the local DNS cache is where the
info will be remembered.  My impression is that there are a lot of
large sites whose MTAs work this way.

This is certainly the case historicaly, but this approach is largely
due to the very poor performance and stability of early editions of 
pthreads, problems that are long since fixed.

I do not know what the situation is where dedicated edge servers 
such as spam filtering systems are concerned. I strongly suspect 
that these are based on very different architectures. Perhaps someone
could go and look at what some of these systems do.

Even on a UNIX box there are good reasons to prefer a per thread model
to a per process model, process creation and teardown in UNIX is only 
lightweight compared to other O/S. 


There are also other ways that a UNIX system may be organized. For 
example if I was operating a large cluster of mail filters I would 
hive off the task of fetching MARID data and resolving all forms
of reputation and accreditation data in a separate system that 
performed caching.

I would not want to store state in the mail server itself for the
reason you mention and also because that would load up my external
connections (which I pay for) rather than my internal 1Gb ethernet
connections which are essentially free.

So no, I do not accept this as much of an argument. Block records 
allow better efficiency in either case.


The only argument I see for factored records is on the maintenance
side where the records are being synthensized automatically via
some form of dynamic DNS. If you have block records you have to 
either define a custom update protocol (trivial via a web service but
must be done) or the dynamic DNS has to read the record, work out the 
update and write back the update.

Of course this could also be solved if the mailer in this case used
the sender header to give a unique machine address e.g.:

Sender: mailer(_at_)pbaker-pc(_dot_)verisign(_dot_)com  
From:pbaker(_at_)verisign(_dot_)com

So the MARID record for pbaker-pc.verisign.com would consist of a 
dynamic dns updated record for my laptop PC and a link to another 
record giving info like accreditation data for the domain as a whole.

OK we don't need factored records here either.

                Phill


<Prev in Thread] Current Thread [Next in Thread>