[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A mail-relay problem



>       Hi,
>       We are the service porvider of Internet in Turkey.
>  There are many sites connected to us and many of them are connected 
>  by TCP/IP over X.25.And we do not call them to connect, instead they
>  call us when they wish to establish connection.
>       If any site tries to make smtp connection to such hosts when they 
> are connected to us, there is no problem. If they are not connected, mails 
> are queued and even returnes back to sender at the site that tries to make 
> smtp connection.
>       I want to let any of our workstations receive such mails (those 
>  are not in its domain) and wait until such hosts connect to us to forward
>  them.I can have that workstation receive those mails using mx records but
>  how can I make those mails wait until the host (that the mail is supposed
>  to arrive at) establishes connection?
> 
>       I wish to do this using "zmail" if possible.
>       Could you please help me to solve the problem ?
>       Any comments are welcome.

	Basically what I have done in similar situation is:
		foo.domain.	IN A	12.34.56.78
				IN MX	10 foo.domain.
				IN MX	20 my.gateway.
		*.foo.domain.	IN MX	10 foo.domain.
				IN MX	20 my.gateway.

	Now when the sender can't reach the real target system
	(for example it being a dialup, or behind a route/access
	 filter) the email gets spooled to   "my.gateway.", which
	can have its own queueing policies instead of the default
	on the sendmail...

	With Zmailer's scheduler the queue retry is done with (example):
		interval=1m
		retries="1 1 2 3 5 10"
		expires=14d
	meaning that the timing unit is one minute, and retry backoff
	is sequenced as: 1, 1, 2, 3, 5, 10, 10, 10, 10, ...
	(And have LONG expiry :-)  My local domain expiry is 30 days,
	 maybe 14 days is enough ?  The common default is 3-5 days.)

	To get all the email via SMTP under such a setup, dialup
	connection should be kept open for at least 20 minutes plus
	whatever it takes to transfer the data.

	This lack of immediate start is a generic problem which could
	be solved with SMTP's "TURN" command (except that nobody
	implements it...)

	To avoid a need to define a huge bunch of queue definitions:
		smtp/*some.domain.
			exires=14d
			interval=1m
			retries="1 1 2 3 5 10"
			command=smtp
		smtp/*other.domain.
			exires=14d
			interval=1m
			retries="1 1 2 3 5 10"
			command=smtp
		smtp/*yet.other.
			...
	it may be neater to define some "routes":
		.some.domain	dialupsmtp!some.domain
		.other.domain	dialupsmtp!other.domain
	which needs defining proper channel definition
	also into  rrouter.cf, and crossbar.cf -- add
	the "dialupsmtp" as an alias to "smtp".
	Then define ONE definition on the  scheduler.conf:
		dialupsmtp/*
			exires=14d
			interval=1m
			retries="1 1 2 3 5 10"
			command="smtp -c dialupsmtp"


	To be more efficient, I do suggest that X.25 is used as a PAD
	connection, and UUCP (F- or G-protocol?) to be used over it.

	Usually -- the way I use IP -- we buy bandwidth, not transferred
	bytes, as is done with X.25...  Thus if the only use for the IP-
	over-X.25 is for SMTP, I do consider it inefficient and expensive.
	(If you have unusual tariffs -- fixed price in between two systems
	 independent of transferred data -- then the economics may differ..)

	After all, the OLD definition of the Internet was regarding IP-
	connectivity, but the CURRENT is about EMAIL CONNECTIVITY :-)

>  Thanks.
>  
>  Namik Kemal Gunel
>  Middle East Technical University
>  Computer Center - Network Group
>  namik@knidos.cc.metu.edu.tr

	/Matti Aarnio	<mea@utu.fi>