wietse:
What is wrong with matching the time of delivery with "ls -t"?
under pressure it's harder if you have 500 message files per minute.
Remember that delivery status information can be sent to random
people with NOTIFY=SUCCESS.
Oh, you're right! I wasn't aware of that point. Thanks!
An
On 11/24/2014 02:25 PM, Darren Pilgrim wrote:
> You can't use policy services with the smtp client, only the smtp server.
Weitse's proposal to use tcp tables is probably a better approach
anyways, but you can use a policy daemon and route from smtpd. The
point is you're routing *from* smtpd to a
On 11/23/2014 1:46 AM, Peter wrote:
On 11/23/2014 02:10 PM, Wietse Venema wrote:
It could be kludged together with a transport map based on tcp_table
or socketmap, plus some clever scripting to generate the right
transport map responses.
I think a more elegant solution that should work would b
I realized that, when I said Postfix was creating the mailbox but not
putting anything in it, that it was actually Dovecot creating the
mailbox. I turned off Dovecot and low and behold, Postfix is delivering
my mail just fine, Dovecot appears to be the culprit.
--
http://www.fastmail.com - IMAP
A. Schulze:
>
> Steve Drach:
>
> > 1. the logs, especially the local daemon, indicates the message is delivered
>
> that question reminds me about a patch I wrote some months ago.
> I had a host receiving tons of bcc and saving them to a maildir.
>
> The challenge was to combine queue id and me
Steve Drach:
1. the logs, especially the local daemon, indicates the message is delivered
that question reminds me about a patch I wrote some months ago.
I had a host receiving tons of bcc and saving them to a maildir.
The challenge was to combine queue id and message files in the maildir.
I
Steve Drach:
> I'm puzzled. I've been running postfix for several years. Around
> August of 2014 I moved to a new system and reinstalled postfix.
> It's been working fine until last monday when I stopped getting
> email.
What has changed? Does it co-incide with some automatic system update?
>
I’m puzzled. I’ve been running postfix for several years. Around August of
2014 I moved to a new system and reinstalled postfix. It’s been working fine
until last monday when I stopped getting email. Here’s what I know.
1. the logs, especially the local daemon, indicates the message is deliv
Viktor Dukhovni:
> On Sun, Nov 23, 2014 at 05:43:44AM +, Viktor Dukhovni wrote:
>
> > It applies to Postfix
> > 2.12 snapshots. [ It conflicts with the IDNA for TLS patch I sent
> > off-list to Wietse in that a new header file #include is added to
> > src/smtp/smtp_addr.c in the same place by
John:
[ Charset windows-1252 converted... ]
>
> On 11/23/2014 9:50 AM, wie...@porcupine.org (Wietse Venema) wrote:
> > John:
> >> however, I had a similar problem a while back, Google would randomly
> >> reject email for, to me, no good reason.
> >> It turned out that with IPv6 postfix was not con
On Sun, Nov 23, 2014 at 05:43:44AM +, Viktor Dukhovni wrote:
> It applies to Postfix
> 2.12 snapshots. [ It conflicts with the IDNA for TLS patch I sent
> off-list to Wietse in that a new header file #include is added to
> src/smtp/smtp_addr.c in the same place by both patches. ]
Oops that c
On Sun, Nov 23, 2014 at 07:23:55AM -0500, Deeztek Support wrote:
> Any thoughts on this?
I have no comment on the irrelevant info I did not ask for. You
could start by answering the questions I asked in my previous
message.
--
Viktor.
On 11/23/2014 9:59 AM, John wrote:
If you can explain why adding the stanzas to master "cures" the problem
I am all ears!
It didn't. Some other factor (e.g., path or load problems with HE's
nameservers) is the real culprit. Google's DNS lookup paths are overly
sensitive to resolution delays
On 11/23/2014 9:50 AM, wie...@porcupine.org (Wietse Venema) wrote:
John:
however, I had a similar problem a while back, Google would randomly
reject email for, to me, no good reason.
It turned out that with IPv6 postfix was not consistent in binding an
address for sending.
Please do not spread
deoren:
> The question I had would have been better phrased as, "Is there a way to
> limit which clients can claim to be from your domain(s) when sending mail?"
>
> After doing some additional digging it looks like "Envelope sender
> address authorization" is what I'm looking for?
>
> http://www.
John:
> however, I had a similar problem a while back, Google would randomly
> reject email for, to me, no good reason.
> It turned out that with IPv6 postfix was not consistent in binding an
> address for sending.
Please do not spread unnecessary confusion.
If you had read this tread more care
Zitat von John :
On 11/22/2014 9:45 AM, Robert Schetterer wrote:
Am 22.11.2014 um 14:50 schrieb A. Schulze:
wietse:
A. Schulze:
So instead implementing strange workarounds, one should search, find,
understand and fix the real problem.
Google bounced my mail because of a temp error. I chan
I forgot to add that the PTR records for both 74.nnn.nnn.178 and
2001:470:dead:beef:nn::178 point to smtp.my.domain which matches the
rest of my setup.
On 11/22/2014 9:45 AM, Robert Schetterer wrote:
Am 22.11.2014 um 14:50 schrieb A. Schulze:
wietse:
A. Schulze:
So instead implementing strange workarounds, one should search, find,
understand and fix the real problem.
Google bounced my mail because of a temp error. I changed nothing
in my DN
On 11/21/2014 3:37 PM, Deeztek Support wrote:
Prove it:
$ cat > issuer.pem <
I guess I'm confused about something. Below are the relevant entries in
my /etc/ssl/certs/ca-certificates.crt file for google. This was obtained
by running the "openssl s_client -CAfile ca.pem -starttls smtp
-showce
On 11/23/2014 02:10 PM, Wietse Venema wrote:
> It could be kludged together with a transport map based on tcp_table
> or socketmap, plus some clever scripting to generate the right
> transport map responses.
I think a more elegant solution that should work would be to create a
policy daemon that w
21 matches
Mail list logo
