headers
Arnt Gulbrandsen | 10 Jul 1994 22:13
Picon
Picon

MX optimisation question

Suppose, in two years, that an MTA has a 400K MIME mailing list message to
deliver.  Among the recipients are these three addresses:

user1 <at> domain.com
user2 <at> sub.domain.com
user3 <at> ip-provider.net

The MXes are as follows:

domain.com	MX	10 domain.com
		MX	20 ip-provider.net
sub.domain.com	MX	10 sub.domain.com
		MX	20 ip-provider.net
ip-provider.net	MX	10 ip-provider.net

Not too contrived, I think.

The question is, how may I optimise delivery of the message?  I want to
deliver the message to as few machines as possible, in order to use as
little bandwidth as possible, and to level the load peak when delivering
mailing-list messages.

Would it be OK to deliver the message only to ip-provider.net with three
RCPT commands, without trying to connect to domain.com and sub.domain.com?
If the message were addressed only to user1 and user2, would it still be
acceptable to send the message via ip-provider.net?

Would it be OK to deliver the message to domain.com if sub.domain.com and
ip-provider.net were down, with RCPT commands for user1 and user2?  I'm
not too fond of this one, but it only requires a line or two of code :-)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Perry E. Metzger | 11 Jul 1994 15:26

Re: Content-language


In article <9407110412.AA28893 <at> necom830.cc.titech.ac.jp> mohta <at> necom830.cc.titech.ac.jp
(Masataka Ohta) writes:

>As a non-native users of English and French, it is much better for
>me to be forced to be somewhat familiar with English only than both
>English and French.

>Unless you support all the languages in the world, which is virtually
>impossible, the politically and emotionally correct way is to support
>only a single language.

Esperanto, anyone?

(No, seriously, I suppport English, and not just because I'm an
English speaker -- in spite of all efforts to get people to adopt an
interlanguage the only real de facto international language is
English.)

--
Perry Metzger		perry <at> imsi.com
--
Are American citizens really so neurotically uptight about deviant
sexual behavior that we will allow our entire information
infrastructure to be dictated by the existence of pedophiles?
				-- Bruce Sterling
Permalink | Reply | 0 comments |
headers
BARBARA GAVIN | 11 Jul 1994 18:09

EMail World Conference (DJCQM01)

EMAIL WORLD
The Mail Enabled Technologies Conference and Exposition
November 29 - December 1, 1994 - Boston, MA

WHAT'S HAPPENING?

Like most new technologies our collection of different EMail 
systems, partially glued together with gateways, is experiencing 
its share of growing pains.  Addressing across enclave 
boundaries is a challenge, and the inability to safely exchange 
information objects across these boundaries is much too 
common.  However, there is a solution on the horizon.  To 
overcome these obstacles, convergence must begin to emerge 
and we must work toward superior interoperability and 
interworkability among our many EMail users.  

We invite you to join us in Boston and attend EMAIL WORLD 
presentations given by the leaders of the industry, who will 
debate the issues and report on the progress of finding the right 
solutions and moving along the path toward convergence.  

HIGHLIGHTS OF EMAIL WORLD

Together with conference sponsor DCI, we have developed a 
program that is 100% focused to the technical and managerial 
issues surrounding the new EMail technologies.   Featuring 6 
comprehensive conferences and over 75 sessions, this power-
packed program explores the problems, solutions and latest 
product advances that you must master to survive in today's 
increasingly competitive business climate.
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Gardiner Myers | 11 Jul 1994 23:19
Picon
Favicon

Re: MX optimisation question

RFC 974 states:

   If the list of MX RRs is not empty, the mailer should try to deliver
   the message to the MXs in order (lowest preference value tried
   first).  The mailer is required to attempt delivery to the lowest
   valued MX.  Implementors are encouraged to write mailers so that they
   try the MXs in order until one of the MXs accepts the message, or all
   the MXs have been tried.  A somewhat less demanding system, in which
   a fixed number of MXs is tried, is also reasonable.  Note that
   multiple MXs may have the same preference value.  In this case, all
   MXs at with a given value must be tried before any of a higher value
   are tried.  In addition, in the special case in which there are
   several MXs with the lowest preference value,  all of them should be
   tried before a message is deemed undeliverable.

Thus, the optimization you suggest is not permitted.

An optimization which is permitted and which is performed by sendmail
V8 is to handle mail for recipients at different domains which have
the same set of MX records by sending multiple RCPT commands in the
same delivery.

To do your optimization, you would need a private agreement with
either domain.com or ip-provider.net, at which point RFC 974 need not
apply.

--

-- 
_.John G. Myers		Internet: jgm+ <at> CMU.EDU
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arnt Gulbrandsen | 13 Jul 1994 12:58
Picon
Picon

Index of ESMTP extensions?

Is there any sort of extension index, kind of like Assigned Numbers?
I just talked to a SMTP daemon which supported some things I've never
heard of, EMAL FROM and TICK.              

Perhaps a regularly revised "These RFCs and other docs define internet
mail" RFC would be a good idea.

--Arnt
Permalink | Reply | 1 comment |
headers
Harald.T.Alvestrand | 13 Jul 1994 20:43
Picon
Picon

Re: Index of ESMTP extensions?

An index of things that are standardized would be an EXCELLENT idea.
Perhaps it should also include things that were once suggested or used
in smaller communities, but are NOT standardized?

The EMAL FROM is one of the (failed) alternatives to the SMTP
extension 8BITMIME.
The TICK is a BITNET extension used in BSMTP (batched SMTP).

(we also need an index of all defined header fields.....)

              Harald A
Permalink | Reply | 0 comments |
headers
Paul Robinson | 24 Jul 1994 20:43

Re: Index of ESMTP extensions?

From: Paul Robinson <PAUL <at> TDR.COM>
Organization: Tansin A. Darcos & Company, Silver Spring, MD USA
-----
Based on Information and Belief, on Wed Jul 13, 1994  9:21 am  EST,
Arnt Gulbrandsen <agulbra <at> nvg.unit.no>, allegedly belched out 
the following:

> Is there any sort of extension index, kind of like Assigned 
> Numbers? I just talked to a SMTP daemon which supported some 
> things I've never heard of, EMAL FROM and TICK.              

"EMAL FROM"?  Do you mean "MAIL FROM"?  MAIL FROM is the standard header 
for an incoming message, e.g.

HELO TDR.COM
MAIL FROM: <PAUL <at> TDR.COM>
RCPT TO: <blah...>
DATA
QUIT

TICK, I have found, is quite useful in debugging bad mailing addresses.  
I have a mailing list with over 1,000 people on it.  I get at least 8-10 
bounces every time I mail something out.  The people on the lists are 
sorted alphabetically by domain name, into country code, and then into 
subdomains of nongeographic codes, e.g. all of the people at MCI Mail are 
in a file called "addr.com-k" which is all addresses ending in .COM where
the domain name starts with K through whatever the next letter is.

Sendmail got hosed if the lists were very long - a 300 name list caused 
sendmail to puke and die, so I broke the list into blocks of less than
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark.R.Horton | 29 Jul 1994 05:15
Picon
Favicon

X.400 on the Interent?

Is there any work to create an X.400 e-mail system on the Internet
similar to the existing SMTP system?  If so, are there any drafts
or summaries of what the plans are?

Thanks,

	Mark
Permalink | Reply | 1 comment |
headers
Ned Freed | 30 Jul 1994 17:50

Re: X.400 on the Interent?

> Is there any work to create an X.400 e-mail system on the Internet
> similar to the existing SMTP system?  If so, are there any drafts
> or summaries of what the plans are?

Work has been underway to do exactly this for many years, and there is  a
substantial pilot infrastructure in place at the present time.

The groundwork for all this is defined by RFC1327, which defines the basic
formats for X.400 routing tables. This work is being expanded by the MHSDS IETF
Working Group, which has defined mechanisms for storing X.400 routing
information in both X.500 and in the DNS. Various Internet Drafts are available
that cover this topic (ds.internet.net in the internet-drafts directory,
anything with the string "mhsds" in its name).

The X400OPS group is also involved, in that they are specifying operational
requirements for X.400 usage on the Internet. You'll find several of their
documents available as Internet Drafts as well, I believe.

A substantial number of RFCs have also been published in this area. Here's a
partial list:

1649  I    R. Hagens, A. Hansen, "Operational Requirements for X.400  
           Management Domains in the GO-MHS Community", 07/18/1994. 
           (Pages=14) (Format=.txt) 
1648  PS   C. Cargille, "Postmaster Convention for X.400 Operations", 
           07/18/1994. (Pages=4) (Format=.txt) 
1616  I    E. Huizer, J. Romaguera, RARE WG-MSG Task Force 88, "X.400(1988)  
           for the Academic and Research Community in Europe", 05/19/1994.  
           (Pages=44) (Format=.txt) (RTR 10) 
1615  I    J. Houttuin, J. Craigie, "Migrating from X.400(84) to X.400(88)",
(Continue reading)

Permalink | Reply | 0 comments |

Gmane