Is there a way to prevent courier from rewriting mime boundaries?
A big provider in our country uses greylisting, so many of our mails can't be
deliviered because courier creates new boundaries on every resend :-(
thx
Oliver
---
The SF.Net
From: David Somers [mailto:[EMAIL PROTECTED]
Greetings,
I've just started playing with Courier 0.48, and almost have a
working system... however, I've hit a stumbling block, and I hope
somebody can yield the answer as to where I've gone wrong.
I've tried to set up courier to do some
Hello,
In my installation of courier (Version 0.45.5 on Suse 9.1)
When I send the following to the smtp port, I receive a 517 Syntax Error.
HELO faxserver
MAIL FROM: +49 235 235 235@faxmaker.com
According to RFC821, however, this should be valid.
I then copied the /usr/lib/courier directory to
On Tuesday 04 January 2005 10:32 am, Frank Mattheus wrote:
Hello,
In my installation of courier (Version 0.45.5 on Suse 9.1)
When I send the following to the smtp port, I receive a 517 Syntax
Error.
HELO faxserver
MAIL FROM: +49 235 235 235@faxmaker.com
The problem is with the TO: line.
Hi Bowie
Did you also add omz13.com to /etc/courier/esmtpacceptmailfor?
Oops. I forgot to add it there.
# testmxlookup garamond.omz13.local
If your courier box can't resolve the name, you need to fix your
DNS resolution.
When I run testmxlookup against omz13.local.zone it just gives a
From: David Somers [mailto:[EMAIL PROTECTED]
When I run testmxlookup against omz13.local.zone it just gives a
rather sad Soft Error. In fact, I get that same error no matter
what domain I specify. Any ideas just what the heck I've done wrong
with my DNS setup?
From the testmxlookup manpage:
My desktop suffered an unplanned reboot this morning, and since then,
courier refuses mail to addresses not listed in the aliases database.
The error is 550 User unknown. Mail to my own account, or root, or
postmaster, all draw that error; but mail sent to my pager alias as
defined in a file in
Jason L. Buberel [EMAIL PROTECTED] wrote:
Found the following sequence in my logs this AM (courier v0.47). What I
found odd was that courier reported the SPF failure in the logs after
reporting that the message had been delivered:
[...]
There is no evidence of another message in the queue
Hi Bowie.
I know that courier's dns lookup is a bit different that what you get
when you run dig, but I don't remember the details. Maybe someone
else can point you in the right direction.
I hope they can. I've been vailantly searching through the archives for the
answer, but it elludes me.
From: David Somers [mailto:[EMAIL PROTECTED]
All I can suggest is to make sure your /etc/resolv.conf is set up
properly.
My resolv.conf is very simple:
domain omz13.local
nameserver localhost
And yes, named is running on the local machine.
This may or may not be related to your
After putting together a few mailboxes, and a few group mail accounts
with tuned ACLs I hit a it of a snag. MS Outlook 2003 SP1 (and probably
others)
can't see the #shared folders :(
I googled around, but couldn't find anything relevant, nor could I find
anything in the READMEs.
From watching
This happened again in the early hours of the morning.
It is starting to look like it might be system resource leak as
restarting courier-imap doesn't help but rebooting the server does.
This problem was not present in the previous release we were running. -
3.0.3.
I intend to down grade and
Following up to myself with more info: I've just realized that a cron
job running under my account delivers to me successfully. Also, if I
manually craft a message to a bad local address with myself as the
envelope sender (again, in a telnet session to localhost port 25), the
mail delivery status
Here is the header/envelope information on a message that also generated
an SPF failure in my logs. Based on the Received-SPF headers, it looks
like everything passed. Yet the log output corresponding to this message
indicates otherwise (see below):
Delivered-To: [EMAIL PROTECTED]
Return-Path:
Weird... just as a passing observation... shouldn't the BOFH check have
caused the message to be rejected if it failed to pass the SPF checks?
Jason L. Buberel wrote:
Here is the header/envelope information on a message that also generated
an SPF failure in my logs. Based on the Received-SPF
Hi Bowie,
This may or may not be related to your problem, but I'm not sure that
localhost is valid there. Try using a numeric address instead.
domain omz13.local
nameserver 127.0.0.1
Thanks - that was the problem. Great... I'm now one step nearer to
decommissioning my old mail server and
As stated previously, the contents of my BOFH file is:
opt BOFHBADMIME=accept
opt BOFHSPFMAILFROM=pass,none,neutral,softfail,unknown
opt BOFHSPFFROM=pass,none,neutral,softfail,unknown
opt BOFHSPFTRUSTME=1
In the SPF admin UI, it looks like this:
Remote Server ID: disabled
Return Address:
Jason L. Buberel [EMAIL PROTECTED] wrote:
Here is the header/envelope information on a message that also generated
an SPF failure in my logs. Based on the Received-SPF headers, it looks
like everything passed. Yet the log output corresponding to this message
indicates otherwise (see below):
Oliver Jusinger writes:
Is there a way to prevent courier from rewriting mime boundaries?
No. If the remote mail server is incapable of receiving 8bit mail, Courier
must rewrite an 8bit message using 7bit-only encoding.
A big provider in our country uses greylisting, so many of our mails can't
Michael Jinks writes:
I'm starting to think that the problem isn't actually with account
lookups, but with Courier not knowing that it's supposed to accept mail
for my machine. Shouldn't the hostname in /etc/courier/me take care of
that?
Yes, provided the locals and the hosteddomains files don't
Three cheers for brute force. I still don't know what the gist of the
trouble was, but after blowing away my /etc/courier and reinstalling from
scratch, all better.
*shrug*
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get
Jason L. Buberel writes:
HTML content follows
Found the following sequence in my logs this AM (courier v0.47). What I
found odd was that courier reported the SPF failure in the logs after
reporting that the message had been delivered:
Jan 3 07:34:57 colo courieresmtpd:
Justin Murdock writes:
After putting together a few mailboxes, and a few group mail accounts
with tuned ACLs I hit a it of a snag. MS Outlook 2003 SP1 (and probably
others)
can't see the #shared folders :(
I googled around, but couldn't find anything relevant, nor could I find
anything in the
Am Mittwoch, 5. Januar 2005 00:32 schrieb Sam Varshavchik:
No. If the remote mail server is incapable of receiving 8bit mail, Courier
must rewrite an 8bit message using 7bit-only encoding.
Thank you. We will try to send 7bit encoded messages so courier doesn't
encode.
Unfortunately, being
On Tue, Jan 04, 2005 at 06:35:51PM -0500, Sam Varshavchik wrote:
Michael Jinks writes:
I'm starting to think that the problem isn't actually with account
lookups, but with Courier not knowing that it's supposed to accept mail
for my machine. Shouldn't the hostname in /etc/courier/me take
On 31 12 2004 at 5:02 pm -0500, Jeff Potter wrote:
Nope, you can have multiple RCPT TO lines.
Hmm, okay, thanks for enlightening me. I should have read the RFC.
And you wouldn't want to put
the X-Original-BCC line in the message, because if you had multiple
bcc recipients on the same host,
Oliver Jusinger writes:
Am Mittwoch, 5. Januar 2005 00:32 schrieb Sam Varshavchik:
No. If the remote mail server is incapable of receiving 8bit mail, Courier
must rewrite an 8bit message using 7bit-only encoding.
Thank you. We will try to send 7bit encoded messages so courier doesn't
encode.
Ben Kennedy writes:
(Assuming the MTA has one instance of the message and a
separate control file listing the deliver-to's.)
Which I gather is how Courier works...?
Right. There's one copy of a message for all of its recipients (with some
exceptions that are not germaine to the purpose of this
Sam Varshavchik wrote:
Justin Murdock writes:
Is it possible to configure Outlook to know about the # marked folder,
From what I recall reading some time ago, no.
But that's just hearsay. You should try the appropriate microsoft.*
Usenet newsgroup.
Ugh. I'm not sure I've got the stomach for
Ben Kennedy [EMAIL PROTECTED] wrote:
In other words, if you are trying to BCC something to both me and my
enemy, it is incumbent upon your outbound service to keep them separate
and private. If both my enemy and I happened to live on the same host,
our inbound SMTP would be providing a
Download: http://www.courier-mta.org
This errata release removes a wayward signal that kills proxied IMAP
connections after a minute.
This is the only change, which affects the new IMAP/POP3 aggregator function
only.
pgpuQROH2g5aW.pgp
Description: PGP signature
31 matches
Mail list logo
