Philip Hazel wrote:
On Fri, 3 Feb 2006, Kenevel wrote:
Following on from this, surely the VERP section in the documentation needs
revisiting if setting return_path is redundant?
I have not followed the details of this thread, but, for a message
delivered over SMTP, you can change the
On Fri, 3 Feb 2006, Bill Hacker wrote:
Hmmm how about web-alizing those 'as is' in one iFrame,
and putting the old-style 'topic/ alphabetical director' index in the a side
bar in another frame? Created by an external process?
I'm sure that Nigel, who was hoping to think more about the
On Thu, 2 Feb 2006, Marc Sherman wrote:
You should set the VERP return path in your verp_outbound_router using
errors_to, instead of using return_path on the verp_smtp transport.
Philip, should the docs in chapter 44.3 be changed to suggest this?
Noted to think about next time the docs are
Philip Hazel wrote:
On Thu, 2 Feb 2006, Marc Sherman wrote:
You should set the VERP return path in your verp_outbound_router
using errors_to, instead of using return_path on the verp_smtp
transport.
Philip, should the docs in chapter 44.3 be changed to suggest this?
Noted to think about
Kenevel wrote:
Is there a way of avoiding having to maintain identical code in two
different places?
I have only errors_to set in my VERP router. You only need return_path in
the transport if you want to override errors_to. The errors_to address is
saved in $return_path, btw.
--
## List
Kenevel wrote:
Is there a way of avoiding having to maintain identical code in two
different places?
A macro.
- Jeremy
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list -
Jakob Hirsch wrote:
Kenevel wrote:
Is there a way of avoiding having to maintain identical code in two
different places?
I have only errors_to set in my VERP router. You only need
return_path in the transport if you want to override errors_to. The
errors_to address is saved in
On Fri, 3 Feb 2006, Kenevel wrote:
Following on from this, surely the VERP section in the documentation needs
revisiting if setting return_path is redundant?
I have not followed the details of this thread, but, for a message
delivered over SMTP, you can change the return path *either* by an
Kenevel wrote:
Hi there,
I've tried the suggested solution of using VERP but am having no luck
testing it.
I must be doing something wrong as although I can see that the return_path
has been set correctly, in that it has the VERP-mangled local_part, the
failure notification which is
snipped
PS: the FTP link to the VERP text available here
(http://exim.org/exim-html-4.60/doc/html/spec.html/ch44.html#id2685805)
doesn't seem to work for me; Google suggests
http://cr.yp.to/proto/verp.txt
Looks like its just the id numbers have been updated..
Marc Sherman wrote:
Can you please resend with a clear explanation of what
you are trying to achieve,
I would like to take advantage of the VERP system of addressing to identify
unavialable mailboxes, and capture any failure notifications in a local
mailbox which, to be read by a different
I stumbled across the errors_to router option and used it to deliver the
local non-SMTP message to the correct mailbox. Do you think it would be
worth including this in the documentation about VERP as well as in the
common config page
Kenevel wrote:
verp_smtp:
driver = smtp
max_rcpt = 1
return_path = ${if match
[EMAIL PROTECTED]
See the documentation for the return_path transport option: Note: If a
delivery error is detected locally, including the case when a remote
server rejects a message at SMTP time, the
Kenevel wrote:
Firstly, I do not want to have the
emails appear to originate at a real mailbox to which addressees can
reply.
This means that anyone doing sender-verification will refuse your mails.
- Jeremy
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim
Kenevel wrote:
Marc Sherman wrote:
Can you please resend with a clear explanation of what
you are trying to achieve,
I would like to take advantage of the VERP system of addressing to identify
unavialable mailboxes, and capture any failure notifications in a local
mailbox which, to be read
Kenevel wrote:
I have a Java web-app through which a club administrator can send out an
invite to someone via email. The reply-to address is currently set to a
noreply, non-existent mailbox, so if someone does try to reply, their
email should bounce and they should be aware that this has
Hi Marc,
The club would be a sports club and the invitees would be its players. In
the sense that the players want to manage their availability through my site
they are solicited.
The club managers inevitably have distribution lists for their club members
and the site provides a means for them
Hi Marc,
No problem about the grilling. Kenevel is a nickname I picked up at uni on
account of having a motorbike. I use this address to subscribe to mailing
lists and registering on websites.
Thanks for the pointer, I think I'll have to read it a few times before it
sinks in.
Cheers
Mike
Hi there,
I've tried the suggested solution of using VERP but am having no luck
testing it.
I must be doing something wrong as although I can see that the return_path
has been set correctly, in that it has the VERP-mangled local_part, the
failure notification which is returned has none of this
19 matches
Mail list logo
