I think the question is:
Why does it *need* to be fixed in the first place, except for the
reason
that it's not RFC compliant?
The way the internet works is defined by the RFCs. Imagine if for some
reason a car manufacturer decided to have the registration/licence
plate on the roof of the car,
Well, one thing that Courier _could_ do when it encounters an
unresolvable MX record would be to try the next MX record in the
series.
The original post said that the MX records look like this:
MX 8 n.n.n.n.
MX 10 mail.foobar.com.
In this case, Courier could t
Is quoting extra "Return-paths" with ">" defined somewhere? (e.g.
rfc?) I'd thought you decided to quote extra "return-path"s to make
it unambiguous which one was the real return-path, to prevent
looping, etc., as a boundary case.
I don't think it's really defined anywhere. It's one of those
Hi list,
(I think I've seen something about this before but didn't found anything
in archives)
When I receive a message, ,courierd logs me an id info (like courierd:
newmsg,id=00291B43.4096B088.78B8: dns; localhost ). I'm trying to
log info about CRM114 [1] filter using logfile/log in maildro
Phillip Hutchings wrote:
> The way the internet works is defined by the RFCs. Imagine if for some
> reason a car manufacturer decided to have the registration/licence
> plate on the roof of the car, not on the back. Sure, it's still there,
> but it's not where it's supposed to be, and instead of ar
Julian Mehnle writes:
Sam Varshavchik [EMAIL PROTECTED] wrote:
MX records contain hostnames, not IP addresses. Normal processing of MX
records will result in the malformed MX record getting ignored (since
the A lookup on the hostname will fail).
So, with none the wiser, the MX record will be igno
Jeff Potter writes:
What other software expects ">Return-path"?
How would changing > to X- break anything?
It's not going to break anything in Courier itself (save for that reformail
bit). As far as other stuff out there, there are no guarantees. All bets
are off.
pgp0.pgp
Description
On Tue, 4 May 2004 00:13:24 +0200
"Julian Mehnle" <[EMAIL PROTECTED]> wrote:
> Phillip Hutchings wrote:
> > The way the internet works is defined by the RFCs. Imagine if for some
> > reason a car manufacturer decided to have the registration/licence
> > plate on the roof of the car, not on the bac
Because obviously a significant number of people misinterprets the
RFC.
More likely, they just have no clue and never read this RFC.
I didn't read the RFC, but I have always used an A record for MX. It
just doesn't seem logical to put IP addresses in places other than A
records, the idea being t
Matthias Wimmer [EMAIL PROTECTED] wrote:
> If there are implementations that try to guess is something is an IP or
> a domain, than they can make wrong assumptions [...]
There's no need to guess. There are no official digit-only top-level
domains, and digit-only top-level domains are not widely u
>
> Isn't it possible to turn of BOFHCHECKDNS selectively in smtpaccess?
> (And yes, the sender should fix their systems!)
>
Yes, it is. If the offending MX is
MX 10 n.n.n.n
you can put
n.n.n.n allow,BOFHCHECKDNS=0
in smtpaccess.
Carey
Matthias Wimmer <[EMAIL PROTECTED]> writes:
> Hi Carey!
>
> Carey Jung schrieb am 2004-05-03 08:26:15:
>> Good question. It just adds to my administrative burden. Also, in my
>> current case, the sending MX records look like this:
>>
>> MX 8 n.n.n.n.
>
> By adding the final "."
Sam Varshavchik wrote:
Your only option is to turn off BOFHCHECKDNS, which turns off ALL dns
checking, letting in all sorts of crap.
It's much better to tell the sender to fix their dns.
Isn't it possible to turn of BOFHCHECKDNS selectively in smtpaccess?
(And yes, the sender should fix their
John Bossert wrote:
0.45.4. Had an email with an attached PDF file rejected with
"improperly formatted binary content." I've read the FAQ and manpages
on BOFHBADMIME, but before I enable it and say "just send me junk", is
there any reasonable means of analysis?
I'm told that email (with pdf
Hi Carey!
Carey Jung schrieb am 2004-05-03 08:26:15:
> Good question. It just adds to my administrative burden. Also, in my
> current case, the sending MX records look like this:
>
> MX 8 n.n.n.n.
By adding the final "." to this record you already noticed, that also
what the
> Sam Varshavchik [EMAIL PROTECTED] wrote:
> > MX records contain hostnames, not IP addresses. Normal processing of MX
> > records will result in the malformed MX record getting ignored (since
> > the A lookup on the hostname will fail).
> >
> > So, with none the wiser, the MX record will be ignor
Sam Varshavchik [EMAIL PROTECTED] wrote:
> MX records contain hostnames, not IP addresses. Normal processing of MX
> records will result in the malformed MX record getting ignored (since
> the A lookup on the hostname will fail).
>
> So, with none the wiser, the MX record will be ignored. This ma
Carey Jung writes:
Your only option is to turn off BOFHCHECKDNS, which turns off ALL dns
checking, letting in all sorts of crap.
It's much better to tell the sender to fix their dns.
Okay, I'll do that. In this case, the DNS hosting firm is local, so I
should be able to do this.
I'm curious, tho
John Bossert writes:
Is there any sort of analysis I can run to see what the problem is/was
(and what I might say to the postmaster at the other site to "fix" things?)
Here's what I'm getting:
Take the whole message, and look for 8-bit characters.
tr -d '\0-\177' will find them. Since the head
19 matches
Mail list logo
