On 18 Apr 2018, at 19:03 (-0400), Erwin wrote:
> RFC 5821 seems rather elusive. Where can one not in the know find a copy?
That was a typo. the quoted text was from RFC5321
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Curre
On 04/18/2018 05:49 PM, Al Iverson wrote:
If you're downloading all your O365 mail and pulling the IP out of that
header, then it's always going to be in the same format and dealing with
it is trivial. Beyond that, when would it be safe to trust this received
header, anyway? Unless it's the mos
If you're downloading all your O365 mail and pulling the IP out of
that header, then it's always going to be in the same format and
dealing with it is trivial. Beyond that, when would it be safe to
trust this received header, anyway? Unless it's the most recent one,
could it not be faked?
In the p
So the only bit we're missing is wrapping the IP literal in []'s.
I'll see if I can get that looked at, but somehow I doubt they're gonna do
anything because after years of doing it this way ...
There are many dependencies internally. ☹
Aloha,
Michael.
--
Michael J Wise
Microsoft Corporatio
On 19/04/18 00:03, Erwin wrote:
> RFC 5821 seems rather elusive. Where can one not in the know find a copy?
Sorry, typo. 5321.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
ISTR that we do it the way we do because we didn’t want to do an, “Off The Box
Call” even to look up the rDNS.
Would love to see us go back to the previously-noted format, but I doubt that’s
going to happen.
And there are so many other formats out there.
Aloha,
Michael.
--
Michael J Wise
Micro
RFC 5821 seems rather elusive. Where can one not in the know find a copy?
On Wed, Apr 18, 2018 at 3:40 PM, Jeremy Harris wrote:
> On 18/04/18 23:03, Michael Wise via mailop wrote:
> > Sorry, what section of 2821?
>
> 5821 has
>
>
> 4.4. Trace Information
> "MUST insert trace ("time stamp" o
Section 4.1.2 defines address-literal:
address-literal = "[" IPv4-address-literal /
IPv6-address-literal /
General-address-literal "]"
; See section 4.1.3
Section 4.1.3 provides specifics for IPv4 (and IPv6 as Brandon kind
While you are right the RFC's say you should enclose dotted quad in some
places in the email transaction, when it comes to 'Received' lines,
there is a little more 'free for all'.
These so called 'trace' fields are covered in RFC5322 and RFC5321
"Received:" header fields of messages originatin
On 18/04/18 23:03, Michael Wise via mailop wrote:
> Sorry, what section of 2821?
5821 has
4.4. Trace Information
"MUST insert trace ("time stamp" or "Received")"
"The FROM clause, which MUST be supplied in an SMTP environment,
SHOULD contain both (1) the name of the source host as
> On Apr 18, 2018, at 2:40 PM, Erwin wrote:
>
> Hi,
>
> This may be old hat to some, but staring at the RFCs (specifically 2821) the
> only conclusion I see is that Microsoft is (or at least *.outlook.com servers
> are) violating the format of the Received headers here:
>
> Received: from mt
RFC 5321 4.4 ie "Extended-Domain" is how they're supposed to be shown. The
IP is an address-literal which is supposed to be in brackets ([]), which to
be fair, I don't think
we do the right thing with ipv6 (which is supposed to have a prefix on the
ip, ie [IPv6:2001:41c8:51:83:feff:ff:fe00:a0b])
Sorry, what section of 2821?
With all the different styles of Received: headers out there (Qmail comes to
mind…), I wasn’t aware that there was in fact a single standard on the format.
I mean, I really love the ( [n.n.n.n]) structure and all, but … If you
could point me to a MUST reference,
Hi,
This may be old hat to some, but staring at the RFCs (specifically 2821)
the only conclusion I see is that Microsoft is (or at least *.outlook.com
servers are) violating the format of the Received headers here:
Received: from mta.email.thinkgeek.com (66.231.88.32) by
SN1NAM04FT019.mail.protec
Hi guys,
Has anyone had trouble getting IP blocks removed from Earthlink? We've
submitted several times for 2 IPs of a client that has recently migrated into
new IP range, but no response (other IPs are getting removed promptly).
If someone is available to take a look and can contact me off-list,
I talked to Gmail Postmaster and they are already aware of it and working
on this issue. There is no ETA on it yet.
Thanks,
Mohammed.
On Wed, Apr 18, 2018 at 10:22 AM, Allen Kevorkov via mailop <
mailop@mailop.org> wrote:
> Indeed... a number of folks have confirmed data is missing for them. A
Indeed... a number of folks have confirmed data is missing for them. Any
insight into this? Many were hoping it would've fixed itself by now :)
Thanks!
~Allen K
On Wednesday, April 18, 2018, 4:14:07 AM EDT, Bressier Simon
wrote:
Hi Brandon,
I'm sure you're already over aware that da
Hi Anthony,
I'm not sure what the consensus is on job adverts. I have an opening too.
But I would prefer it if you keep it away from this mailing list.
Email deliverability is a small world. Maybe you can use twitter for job
openings... #email #deliverability #job ...
Yours,
David
On 17 April
Thanks for all your input on this question, people! Much appreciated.
-Annalivia
Regards,
Annalivia Ford
Email Services Manager, EMEA
Phone: +31 (0)6 53 32 34 44
eMail: annalivi...@nl.ibm.com
From: Brandon Long via mailop
To: John Levine
Cc: mailop , Ned Freed
Date: 1
Hi Brandon,
I'm sure you're already over aware that datas are stopped on 11th of April
on G postmaster on FBL, authentication, spam rate.
Just wanted to check if you already had an ETA of fix, and if it will be
retroactive ?
Thank you very much in advance.
Simon
20 matches
Mail list logo
