On 21 April 2018 at 18:24, John Levine wrote:
> In article you write:
>>Am I missing a case where there is a negative outcome to a legitimate,
>>by-the-book sender?
>
> Spammer forges header with address of unrelated network, that network
> gets listed even though it has never sent spam and has n
Parenthesized text is optional.
From-domain = "FROM" FWS Extended-Domain CFWS
Extended-Domain = Domain /
( Domain FWS "(" TCP-info ")" ) /
( Address-literal FWS "(" TCP-info ")" )
in this case domain matches "Domain" (and thouse matches
Extended-Domain) and parenthesized
> On Apr 21, 2018, at 10:27, Vladimir Dubrovin via mailop
> wrote:
>
>
> According to RFC 2822, text in () represents comment (see section 3.2.3) and
> is used in the place where RFC2821 allows CFWS. CWFS is allowed to contain a
> comment (it's what differs FWS from CFWS).
>
> So, while t
I was specifically talking about querying a DNSBL with possible-forged IP
addresses, not creating new listings or anything else.
That wasn't clear.
Anyway, you normally only look up the IP of the gateway host that sent the
mail from their network to yours. Relays before that are often from h
On Sat, 21 Apr 2018 12:19:02 -0400, Al Iverson
wrote:
>It blacklists an unrelated party, is my point. Not only is it unfair,
>but it makes for pretty useless and sloppy spam fighting.
My personal experience is that, even if no listing occurs, there will be time
wasted responding to "screaming pi
> On Apr 21, 2018, at 10:24, John Levine wrote:
>
> In article you write:
>> Am I missing a case where there is a negative outcome to a legitimate,
>> by-the-book sender?
>
> Spammer forges header with address of unrelated network, that network
> gets listed even though it has never sent spam
According to RFC 2822, text in () represents comment (see section 3.2.3)
and is used in the place where RFC2821 allows CFWS. CWFS is allowed to
contain a comment (it's what differs FWS from CFWS).
So, while this format is not optimal for automated parsing, it does not
violate RFCs.
19.04.2018 0:
In article you write:
>Am I missing a case where there is a negative outcome to a legitimate,
>by-the-book sender?
Spammer forges header with address of unrelated network, that network
gets listed even though it has never sent spam and has no relation to
the spammer.
R's,
John
On Sat, Apr 21, 2018 at 12:29 AM, Dave Warren wrote:
> Am I missing a case where there is a negative outcome to a legitimate,
> by-the-book sender?
Yes.
It would be like if I started adding a faked received header to my
spam (if I were a spammer) that always included a reference to your
outbound
On 2018-04-18 17:49, Al Iverson wrote:
In the past I've had to deal with DNSBL listings based on faked
received headers-- IMHO, it's not safe to parse IPs beyond connections
that you yourself have verified.
I've always considered this a feature, not a bug. Spammer forges their
way into getting
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
t; Aloha,
>
> Michael.
>
> --
>
> Michael J Wise
> Microsoft Corporation| Spam Analysis
>
> "Your Spam Specimen Has Been Processed."
>
> Got the Junk Mail Reporting Tool ?
>
>
>
> -Original Message-
> From: mailop On Behalf Of Jeremy H
:41 PM
To: mailop@mailop.org
Subject: Re: [mailop] Received header address information
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")"
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
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Got the Junk Mail Reporting
Tool<http://www.microsoft.com/en-us/download/details.aspx?id=18275> ?
From: Erwin
Sent: Wednesday, April 18, 2018 3:58 PM
To: Michael Wise
Cc: mailop
Subject: Re: [mailop]
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,
23 matches
Mail list logo
