Could someone with a clue at Xtra please have a look and make sure that mta*.xtra.co.nz are (still) inserting X-Rcpt-To headers? In many cases this just isn't possible... like, if a message goes to more than one person. Hmm... come to think of it, they use Intermail/Openway which stores messages headers separate from message bodies in an SQL database or something evil, so perhaps it is possible... --cw --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

Insert a header

X-Martins-Header: foo

Yup, good idea! And yes I was already doing that on the lists I host; the loops were occuring on lists hosted elsewhere. But on my lists, the posters still got a "loop detected" message for each message they sent; even though I could explain it to them, they were getting rather peeved because it took me about 3 weeks to track down the email address in the list that was causing the problem (it went away and came back a few times). But the problem remains that mail which is correctly addressed doesn't get delivered, and the people who are affected by it are those least able to understand what's gone wrong. -Martin --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

At 23:20 6/06/2001, DPF wrote:

On Wed, 6 Jun 2001 09:34:02 +1200, you wrote:

...

Has anyone else noticed a recent downturn in mail deliverability for domains hosted by Xtra?

In particular, in the last month I have had 3 mailing lists royally screwed by having various clients of Xtra decide to disregard the envelope addressee and send the mail back into the list injection point. The common features in all cases have been

the primary MX is mta.xtra.co.nz the mail is collected from there using a POP client the mail is then fed to an Exchange Server

I've had this problem with Xtra for several months now so it isn't recent. It does indeed bugger up mailing lists badly. As Joe or someone suggested the short-term solution is inserting a taboo header.

Xtra IT Ops staff have had information back from the supplier of our SMTP software on header rewriting, but are not sure the facility they talk about will do what we want. They're going to do some experimenting to see what can be achieved. -- Ted Grenfell Xtra ISP Performance Manager Mob 025 435 455; DDI 09 359 5854; Fax 09 362 8100 Level 13, Telecom Tower, 16 Kingston St, Private Bag 92028, Auckland --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

On Thu, Jun 07, 2001 at 09:42:30AM +1200, Brian Gibbons wrote: If TED.G(a)xtra.co.nz is an alias of TEDG(a)xtra.co.nz then only one message is placed in the box. Sounds like a feature not a bug :) Historically, sendmail has done duplicate removal with aliases for many years, and since it has such dominance most MTAs have copied/emulated this behaviour. --cw --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

Chris Wedgwood wrote:

On Thu, Jun 07, 2001 at 09:42:30AM +1200, Brian Gibbons wrote:

If TED.G(a)xtra.co.nz is an alias of TEDG(a)xtra.co.nz then only one message is placed in the box.

Sounds like a feature not a bug :)

Yep. The bug here is people using POP as a mail transport protocol. It's not. It's a mailbox retrieval protocol. Putting a messaging into a mailbox loses its envelope address information. Sure, you can hack the header to retain that information, but it's a dreadful non-standard hack. If you really must use POP to retrieve multiple users' mail, use multiple mailboxes and query 'em all. Better still, use a real transport protocol. SMTP with ETRN or dial-up triggering strikes me as a *much* better (if not perfect) solution. -- don --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

Ben Aitchison wrote:

Why's UUCP so evil? It's the best suited solution here. SMTP with ETRN is rather a hack. UUCP is a solution that works well for non well-connected hosts such as dial-up users.

Well, if all you want is email, then uucp works just fine. Except that it's a whole bunch of stuff most ISPs don't want to deal with anymore, especially on their dialup servers. (Is this a PPP call or a uucp call?) You can of course run uucp over TCP, but that means running an error correcting protocol over an already reliable protocol. In a word, yuck. Many, many moons ago, I used a hybrid of both -- I used uucp for all mail to my domain; when I had my (rather hacky) 14.4 kbps dialup IP connection active, the uucp client would connect to the uucp server over TCP, other times it would do a normal uucp dialout. Like I said: yuck. Around '94 or so I put in a leased line with 28.8 kbps modems, switched the mail to SMTP and was *much* happier ...

That said, SMTP w/ ETRN fits in a lot easier with a lot of US-centric software that assumes the user is always connected.

Well, it fits better with the Internet. Internet protocols generally do. -- don --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

Chris Wedgwood wrote:

On Thu, Jun 07, 2001 at 04:13:12PM +1200, Don Stokes wrote: You can of course run uucp over TCP, but that means running an error correcting protocol over an already reliable protocol. In a word, yuck.

Its hardly a crime, IP has checksums as do ethernet frames, as so other encpsulation technologies...

Well, no, but then ethernet (in common with every other sensible link level protocol) doesn't send acknowledgments. TCP does and uucp (g protocol at least) does, so you have a bunch of TCP packets flying back to the other end carrying uucp acknowledgments. You're also carrying more data, as you send the uucp protocol overhead on top of the TCP, IP and link level stuff. And you get uucp's windowing rules kicking in before TCP's do (once the transfer is underway), even if you adjust your uucp parameters to maximum window and packet sizes -- the defaults are small enough that any amount of latency slows things down quite badly and even the maximums are often not enough with V.42bis and friends plus latencies from TCP packetising and network delays in the way. uucp is a batch serial line file transfer protocol. It happens to have mail and news transfers layered on top of it, but it's still a serial line protocol. You wouldn't transfer mail with Kermit, would you? (Actually, I've heard of that being done too...) Pete wrote:

But of course you also gain the benifit of using a protocol that can incorporate compression, which can be a saviour on low-speed links, like rural dialup customers. In a word, nice.

You wish. Compression was a feature of uucp news transfer, but not mail transfer, i.e. news batches would be compressed, then put in the queue to send, while mail just got a From_ line prepended and an rmail command for the message submitted. Anyway, text compresses nicely with modern modems. Oh, IME, most PC uucp packages are garbage anyway. Yuck. -- don --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

Chris Wedgwood wrote:

On Fri, Jun 08, 2001 at 09:45:31AM +1200, Don Stokes wrote:

Well, no, but then ethernet (in common with every other sensible link level protocol) doesn't send acknowledgments. TCP does and uucp (g protocol at least) does, so you have a bunch of TCP packets flying back to the other end carrying uucp acknowledgments.

Eh? What the hell are you on about?

The point I was making is that multiple layers of checksumming is hardly new, nor something I would consider bad (perhaps superfluous, the IPv6 designers choose to drop this and require lower-layers provide checksumming).

Checksums don't make a protocol reliable. Acknowledgement of received packets and retransmission of lost packets does, and layering one reliable protocol over another makes the windowing/retransmission algorithms conflict in a worst-of-both-worlds kind of way. This is yucky. Hey, I've done enough low-level comms hacking to be entitled to my opinions... (I've done uucp over X.25/X.29 too, and that was *much* yuckier.)

Yes, there is additional overhead, but who really cares? How many MUAs and MTAs support BDAT (rfc3030 ???) to avoid the >33% expansion that base64 encoding gives to attachments?

MIME is *very* yucky. The problem here is RFC 822 and its 7-bit ASCII requirement, not in the transport, so trying to fix it down at the SMTP layer (e.g. via BDAT) is very messy. RFC 822's 7 bit ASCII requirement was a mistake, albeit an understandable one back in the days when nobody could really agree on how many bits constituted a character. Anyway, just because something is yucky doesn't make adding more yuckiness OK. -- don --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

On Thu, 14 Jun 2001, Dean Pemberton wrote:

This might be starting to get a little off topic.

Although it is moderately interesting. David Robb --- Senior Network Engineer DDI +64-9-359-2710 ihug (AS7657) NOC +64-9-359-2708 "The Earth is a single point of failure" --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

Careful - I'll find that you have defamed me =) On Thu, Jun 14, 2001 at 01:33:39PM +1200, Juha Saarinen wrote:

:: On Thu, 14 Jun 2001, Dean Pemberton wrote: :: :: > This might be starting to get a little off topic.

Aren't "off-topic" complaints off topic too?

--------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

Our MTA seems to get lots of these from mta.xtra.co.nz

Your message has encountered delivery problems to the following recipient(s):

**********@xtra.co.nz Delivery failed 452 Too busy to accept mail right now; try again later Sent: DATA Received:452 Too busy to accept mail right now; try again later

Is it because its Friday and they are all at the pub? Peter Mott Chief Enthusiast 2day.com -/- --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

Don Stokes wrote:

Checksums don't make a protocol reliable.

No, but they do play an important role in some reliable protocols.

layering one reliable protocol over another makes the windowing/retransmission algorithms conflict in a worst-of-both-worlds kind of way.

This can't be true. While it may hold in some instances, as a general statement it can't be right. TCP/IP behaves poorly in situations where bit error rates are high. If the overall latency is also high, but the high bit error rate link has low latency then the effect of placing a reliable protocol underneath TCP/IP (especially one that does forward error correction) on the link will, without doubt, improve real world performance. -Craig --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

Craig Anderson wrote:

...

layering one reliable protocol over another makes the windowing/retransmission algorithms conflict in a worst-of-both-worlds kind of way.

This can't be true. While it may hold in some instances, as a general statement it can't be right. TCP/IP behaves poorly in situations where bit error rates are high. If the overall latency is also high, but the high bit error rate link has low latency then the effect of placing a reliable protocol underneath TCP/IP (especially one that does forward error correction) on the link will, without doubt, improve real world performance.

Different situation. You're not talking about running the lower level reliable protocol over the entire path length, as you are in uucp over TCP. Link layer reliability can be tuned to suit the nature of the link; fast retries are a reasonable thing to do when you know what the latency limit of the link is (more or less), especially if you know it to be short. Across the Internet you don't. If you run fast retries across the 'net, you'd be retransmitting packets that will safely arrive, just a little later than you thought. Put TCP on top of that and you'll still get lots of retries when you don't need them -- exactly the circumstances TCP was designed to avoid. Performance goes down because the link is full of unnecessary retries. Meanwhile, if doing this introduces a lot of latency, TCP's flow control will kick in, even if things are going full tilt at the lower levels. Worst of both worlds. Turn it around, and take a short-packet fast-retry protocol, oh, say uucp[1], and run it over a longer retry, longer packet protocol TCP. If the link experiences packet loss, TCP stops until it times out, and that could be a while. Meanwhile, uucp keeps sending packets, filling the TCP buffers. When the TCP link re-establishes, it ends up sending a full buffer worth of repeated packets. Even if the link has merely a highish latency, you can still get repeated packets, because uucp's retry algorithm is based around serial line latencies, not Internet latencies. So the traffic goes at best the same speed (minus the extra overhead of course), and at worst very much slower. uucp may even give up on the link completely, even when TCP would be perfectly capable of recovering. Worst of both worlds. Yes, if you have two boxes connected together via a slightly lossy link, TCP between those two boxes over a reliable link protocol will work better than TCP over a non-reliable one. But that's a corner case; the general case is much more complicated. TCP is designed to deal with large networks. You wouldn't run V.42 over IP (let alone TCP), because that's not what it was designed for. Not that TCP is perfect, mind. For example, TCP's slow-start can bite hard when there is packet loss, hence the effectiveness of reliable link layer protocols for high bit-error comms. But mixing retry algorithms over the same path does not in the general case make for good comms, especially when one is optimised for the full path and the other isn't. -- don [1] uucp, at least in later implementations, is tunable with long packets and larger windows, which could help. But my own experience was that this is itself limited -- with big packets, any unnecessary uucp retries could greatly drop the performance of the link -- it isn't automatically better to increase the packet sizes. This is true even on serial links, much more so when running uucp over TCP. --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

You can of course run uucp over TCP, but that means running an error correcting protocol over an already reliable protocol. In a word, yuck.

But of course you also gain the benifit of using a protocol that can incorporate compression, which can be a saviour on low-speed links, like rural dialup customers. In a word, nice. Just my $0.02 :) Pete Pete Mundy - Technician Advanced Communications +64-3-546-9169 / +64-25-480-840 E-Mail: Pete(a)AdvComm.Co.NZ --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog