On Sun, 2004-11-07 at 15:56, lee wrote:
> Many thanks Nick and also Jim and Bob for your advice so far;
> You've all mentioned VERP and related issues, which I am doing my best
> to understand. Even though what I talk about below seems to ignore my
> understanding of VERP, I'd be grateful if you could stick with me ...
Um, you need to get a basic understanding of sendmail before you do this
stuff. Return-path is a header that is set by the MTA (i.e., sendmail)
as part of the final delivery and it is simply a conventional way to
preserve the RFC821 envelope address. Setting it before you resend
something is likely useless. It is a way to make this visible to the
mail recipient and will otherwise likely be ignored.
> Regarding your smtp question, Nick; I believe mailgust has been
> 'temporarily/partly' coded to just absorb any bounces which come back to
> the mlm. It's acknowledged that the software is incomplete in this area,
> including my issues with the sendmail sending.
So the answer is that "smtp" is, in fact, mailgust code? But, for some
reason, you have decided to call sendmail directly.
> I was talking to the developer yesterday although he is committed to
> paid work for now, and he asked a question which indeed I have
> considered but chose to ignore so far - if I am having trouble with mail
> delivery errors going directly to list zubscribers, how could the
> current mailgust state be causing this? ie, the list posting address
> appears in the list headers as the Return-Path, but I know for sure that
> the bounces I and others are experiencing are definitely not being
> remailed out through the list.
Did you understand what I wrote? Please read RFC821 - there are newer
ones, but that one is on point here. When you understand that there is
a MAIL FROM and a RCPT TO address, then consider that what you put in
the mail header has nothing to do with the delivery of the mail.
(With the exception of using the -t option to sendmail - when you do
that, sendmail parses the header, once, and fills in the envelope.)
> Anyway ... he wasn't implying the software was otherwise fine in this
> area; he was simply questioning the effort i was putting into an
> apparent train of logic.
> I also understand from what I have learnt here and elsewhere that the
> header in the eventual mail envelope may be the crux of the issue,
> rather than my understanding of the visible Return-Path header.
No, unless the mail recipient's system is badly broken, the From header
has nothing to do with anything.
I'll try again:
1. There is an envelope. The envelope is how one sendmail talks to
another - the "MAIL FROM:<your list bounce address>" "RCPT TO:<someone
getting your list mail."
Then there is the header of the mail, which is mostly secondary to
everything. It contains hints and clues about how a mail user agent is
to flag the mail, some trace information, and some other stuff. Pretty
much nothing there matters to either the mail delivery, or to the bounce
of non-deliverable mail.
Good mail transfer agents return bounces to the MAIL FROM:<> address,
and not to anything in the headers. There are exceptions, but these
mostly occur when people who think that they understand e-mail but don't
(like Lotus or Microsoft) write products. Good MTAs (sendmail, postfix,
qmail) send their bounces to the RFC821 envelope (although more and more
people are simply sucking up bounces because of rampant origin
> So .... the easiest thing for me to do here is just show you (below) the
> latest mail I have sent to the mailgust support list. If you understand
> php and have the time and interest, it shows the current state of my
> 'efforts' and limits of understanding!
I've read it, and I think you are manipulating the "Return-Path:"
header. You are wasting your time. Return-Path might be parsed by -t
from sendmail, (I have no way of testing this) but it seems wrong headed
to do that. If you read RFC822 (obsolete but still on point for this)
4.3.1, it talks about making a route path available here - this is the
older mindset where sendmail and RFC822 would gateway from addressing
domain to addressing domain - say from a uunet gateway to the external
world to a private mail system - and the Return-Path would record this,
so that the final recipient would have a fighting chance of replying.
This is broken in today's world, but there is one point:
> This field is added by the final transport system that
> delivers the message to its recipient. The field is intended
> to contain definitive information about the address and route
> back to the message's originator.
Since the RFC821 address would have to be massaged at any gateway to
allow a bounce, simply copying the envelope origin to this header is the
way it works. But putting it into mail that you are sending is
meaningless - expect it to be ignored by the final delivery MTA.
> In case it's relevant, I don't have command line / Unix / shell access
> to set up or configure anything such as sendmail; all I have is cPanel
> type access to my hosting.
If you have the ability to set up scripting, you have the ability to get
an interactive shell on your web host. You just don't know how. :-)
If you are calling sendmail directly to forward the e-mail that is being
generated or forwarded by mailgust, you need to override the origin.
Using the owner- magic might work. Specifying what you want as an
argument to sendmail is more likely to work.
>From the sendmail man page:
> -fname Sets the name of the ``from'' person (i.e., the envelope sender
> of the mail). This address may also be used in the From: header
> if that header is missing during initial submission. The enve-
> lope sender address is used as the recipient for delivery status
> notifications and may also appear in a Return-Path: header. -f
> should only be used by ``trusted'' users (normally root, daemon,
> and network) or if the person you are trying to become is the
> same as the person you are. Otherwise, an X-Authentication-
> Warning header will be added to the message.
I want to point out that whereas the envelope sender might be put into
Return-Path, this does not imply that Return-Path will be copied into
the envelope sender. I could be wrong.
Again, the simple answer is that if you specify the address you want the
bounces to go to, then you don't need to worry.