For that the Transport is too late to achieve it. I'd suggest you look
at the Router options, especially address_data, and play with that.
Check chapter 15ff of the documentation. I did not play with that up
till now, so I don't have a ready made solution for it. But others
might have?!
BTW:
++ 02/10/08 03:29 -0700 - Phil Pennock:
One more thing, you said and assuming that the username is, by this
point, the $local_part being routed. Why wouldn't that be the case?
In my situation, this part of a router which is one of a couple
taking care of the local delivery of the message.
Hi,
People on this list will be interested to know that RFCs 2821 and 2822 (and
some other related RFCs) have been deprecated by the release yesterday of
RFCs 5321 (SMTP) and 5322 (Internet Message Format) respectively.
http://tools.ietf.org/html/rfc5321
Abstract
This document is a
--On 2 October 2008 23:52:57 +0200 Oliver von Bueren [EMAIL PROTECTED]
wrote:
On the transport add the keywords envelope_to_add and return_path_add
to accomplish this. From the documentation you have the following example:
Please don't do this. It will put all the recipients into the
On 2008-10-03 at 09:26 +0200, Rejo Zenger wrote:
Still, I am not sure if I have understood you correctl:
That's okay, I had to read it over myself. The regular user system
code should be read as regular system usercode. I knew there was
something wrong with it but was too tired to parse.
Ian Eiloart wrote:
Hi,
People on this list will be interested to know that RFCs 2821 and 2822 (and
some other related RFCs) have been deprecated by the release yesterday of
RFCs 5321 (SMTP) and 5322 (Internet Message Format) respectively.
I was just browsing RFC 5321 (not finished
Nice write up at...
http://blog.mailchannels.com/2008/10/update-to-email-standards.html
If not already posted here..
--
Martin Hepworth
Snr Systems Administrator
Solid State Logic
Tel: +44 (0)1865 842300
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
On Fri, 3 Oct 2008, Renaud Allard wrote:
I was just browsing RFC 5321 (not finished reading yet)
It seems it implies that exim is not RFC 5321 compliant, for example:
Lines consist of zero or more data characters terminated by the
sequence ASCII character CR (hex value 0D) followed
On Fri, 3 Oct 2008, Renaud Allard wrote:
Yesterday I noticed that the body of these mails does not terminate with
CRLF, there is no line termination at all, and I'm guessing that is the
issue.
Has anyone else observed this?
Yes, MS Exchange only accepts CRLF and doesn't recognize
Hmmm, I think I find the problem. Thanks for all pieces of advice. :-)
When recipient addresses belongs to the same domain router runs only ONCE
for this domain.
So if one of recipients does NOT match the condition criteria (condition
failure)
the router doesn't process the remaining
As a start, Ian, please don't send replay to private address, just to
list. Thanks.
Ian Eiloart wrote:
Please don't do this. It will put all the recipients into the header,
including Bcc recipients.
I know perfectly well what the RFC tells about BCC. But this option does
not what you think
--On 3 October 2008 14:51:32 +0200 Oliver von Bueren [EMAIL PROTECTED]
wrote:
As a start, Ian, please don't send replay to private address, just to
list. Thanks.
It's list policy. I'm not going to try to remember individual preferences
about whether you get a separate reply. If it bothers
Thanx for the comments.
Oliver, i used what you posted in the original response, and did a
test. I sent an email from another account (this one at hushmail)
and i logged in to my localhost on port 25. In both cases the
Received: header (as opposed to to and cc) lines only included the
address
Hello List:
I'm just setting up SSL on my Exim 4.69 and I would like to ask a
question about the certificate.
Do I have to order it in the name of the MX record (which has a
matching A record) or just for the domain without any sub name
prefix.
Thanks,
George
--
## List details at
I'm just setting up SSL on my Exim 4.69 and I would like to ask a
question about the certificate.
Do I have to order it in the name of the MX record (which has a
matching A record) or just for the domain without any sub name
prefix.
Whatever your users (and incoming connections) will think
[EMAIL PROTECTED] wrote:
Hmmm, I think I find the problem. Thanks for all pieces of advice. :-)
When recipient addresses belongs to the same domain router runs only ONCE
for this domain.
So if one of recipients does NOT match the condition criteria (condition
failure)
the router
Martin.Hepworth wrote:
Nice write up at...
http://blog.mailchannels.com/2008/10/update-to-email-standards.html
Quoting writer's interpretation:
Bounces should only be sent if the receiver knows they'll be usefully
delivered. This is code for: Don't sent bounces when your system
rejects
That sounds nice in theory. But how can you ever in a sane manner
determine with reasonable certainty a bounce will be usefully
delivered?
Simple, just tag all outgoing emails with one of those neat footers saying
that This bounce is intended to be useful... and you should be free and
clear
Jeroen van Aart wrote:
Bounces should only be sent if the receiver knows they'll be usefully
delivered. This is code for: Don't sent bounces when your system
rejects spam or virus traffic, or you'll become an Internet pariah.
That sounds nice in theory. But how can you ever in a sane
Marc Sherman wrote:
Jeroen van Aart wrote:
Bounces should only be sent if the receiver knows they'll be usefully
delivered. This is code for: Don't sent bounces when your system
rejects spam or virus traffic, or you'll become an Internet pariah.
That sounds nice in theory. But how can you
Renaud Allard wrote:
Marc Sherman wrote:
Jeroen van Aart wrote:
Bounces should only be sent if the receiver knows they'll be usefully
delivered. This is code for: Don't sent bounces when your system
rejects spam or virus traffic, or you'll become an Internet pariah.
That sounds nice in
21 matches
Mail list logo
