Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: SpamAssassin: users

Received header syntax

 

 

SpamAssassin users RSS feed   Index | Next | Previous | View Threaded


oribani at gmail

Aug 14, 2012, 8:01 PM

Post #1 of 5 (751 views)
Permalink
Received header syntax

Hello,

There are a few changes we want to make to our outgoing email headers,
including to the Received headers that our MTA adds. I know that some
tools including SA have some tests that judge spamminess based on
malformed Received headers, but I have not been able to find anywhere
that describes a definitive valid syntax for that header.

In order to make our changes without doing something that will get us
penalized for invalid Received headers, I'd like to ask for assistance
as to its expected format, in general, or at least as far as SA is
concerned. If I missed a wiki page about it, links would be
appreciated.

Thank you,

Ori


dfs at roaringpenguin

Aug 14, 2012, 8:19 PM

Post #2 of 5 (705 views)
Permalink
Re: Received header syntax [In reply to]

On Tue, 14 Aug 2012 20:01:13 -0700
Ori Bani <oribani [at] gmail> wrote:

> There are a few changes we want to make to our outgoing email headers,
> including to the Received headers that our MTA adds. I know that some
> tools including SA have some tests that judge spamminess based on
> malformed Received headers, but I have not been able to find anywhere
> that describes a definitive valid syntax for that header.

RFC 5321, section 4.4 has a BNF description of a Received: header.

http://tools.ietf.org/html/rfc5321#section-4.4

Regards,

David.


oribani at gmail

Aug 15, 2012, 12:12 PM

Post #3 of 5 (702 views)
Permalink
Re: Received header syntax [In reply to]

On Tue, Aug 14, 2012 at 8:19 PM, David F. Skoll <dfs [at] roaringpenguin> wrote:
> On Tue, 14 Aug 2012 20:01:13 -0700
> Ori Bani <oribani [at] gmail> wrote:
>
>> There are a few changes we want to make to our outgoing email headers,
>> including to the Received headers that our MTA adds. I know that some
>> tools including SA have some tests that judge spamminess based on
>> malformed Received headers, but I have not been able to find anywhere
>> that describes a definitive valid syntax for that header.
>
> RFC 5321, section 4.4 has a BNF description of a Received: header.
>
> http://tools.ietf.org/html/rfc5321#section-4.4

Thank you, although I wonder where the definition of "Protocol" and
"Domain" and some other things are, it's easy enough to guess.

I tried to intentionally make a terribly wrong Received to see if SA
would give me a rule hit but it did not. Is there a rule for this? If
so, how can I turn it on and off?

Is there a place I can test only this rule?


darxus at chaosreigns

Aug 15, 2012, 12:19 PM

Post #4 of 5 (706 views)
Permalink
Re: Received header syntax [In reply to]

On 08/15, Ori Bani wrote:
> I tried to intentionally make a terribly wrong Received to see if SA
> would give me a rule hit but it did not. Is there a rule for this? If
> so, how can I turn it on and off?

I don't think there is actually a rule for unparsable headers. I think it
effectively just ignores received headers it can't parse. So just run one
of your outgoing emails through spamassassin -D and look for lines like:

Aug 15 15:17:33.625 [23043] dbg: received-header: parsed as [. ip=140.211.11.3 rdns=hermes.apache.org helo=mail.apache.org by=panic.chaosreigns.com ident= envfrom= intl=0 id=C6F0CCD227 auth= msa=0 ]

To make sure it has parsed successfully.

> Is there a place I can test only this rule?

No.

--
"I always wonder why birds stay in the same place when they can
fly anywhere on the earth. Then I ask myself the same question."
- Harun Yahya
http://www.ChaosReigns.com


Mark.Martinec+sa at ijs

Aug 16, 2012, 6:20 AM

Post #5 of 5 (715 views)
Permalink
Re: Received header syntax [In reply to]

Ori,

> > RFC 5321, section 4.4 has a BNF description of a Received: header.
> > http://tools.ietf.org/html/rfc5321#section-4.4
>
> Thank you, although I wonder where the definition of "Protocol"

With = CFWS "WITH" FWS Protocol
Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
Attdl-Protocol = Atom
; Additional standard names for protocols are
; registered with the Internet Assigned Numbers
; Authority (IANA) in the "mail parameters"
; registry [9]. SMTP servers SHOULD NOT
; use unregistered names.

> and "Domain" and some other things are, it's easy enough to guess.

Do not guess, stick to RFCs.


RFC 5321
2.3.5. Domain Names

A domain name (or often just a "domain") consists of one or more
components, separated by dots if more than one appears. In the case
of a top-level domain used by itself in an email address, a single
string is used without any dots. This makes the requirement,
described in more detail below, that only fully-qualified domain
names appear in SMTP transactions on the public Internet,
particularly important where top-level domains are involved. These
components ("labels" in DNS terminology, RFC 1035 [2]) are restricted
for SMTP purposes to consist of a sequence of letters, digits, and
hyphens drawn from the ASCII character set [6]. Domain names are
used as names of hosts and of other entities in the domain name
hierarchy. For example, a domain may refer to an alias (label of a
CNAME RR) or the label of Mail eXchanger records to be used to
deliver mail instead of representing a host name. See RFC 1035 [2]
and Section 5 of this specification.

The domain name, as described in this document and in RFC 1035 [2],
is the entire, fully-qualified name (often referred to as an "FQDN").
A domain name that is not in FQDN form is no more than a local alias.
Local aliases MUST NOT appear in any SMTP transaction.

Only resolvable, fully-qualified domain names (FQDNs) are permitted
when domain names are used in SMTP. In other words, names that can
be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
in Section 5) are permitted, as are CNAME RRs whose targets can be
resolved, in turn, to MX or address RRs. Local nicknames or
unqualified names MUST NOT be used. There are two exceptions to the
rule requiring FQDNs:

o The domain name given in the EHLO command MUST be either a primary
host name (a domain name that resolves to an address RR) or, if
the host has no name, an address literal, as described in
Section 4.1.3 and discussed further in the EHLO discussion of
Section 4.1.4.

o The reserved mailbox name "postmaster" may be used in a RCPT
command without domain qualification (see Section 4.1.1.3) and
MUST be accepted if so used.

> I tried to intentionally make a terribly wrong Received to see if SA
> would give me a rule hit but it did not. Is there a rule for this? If
> so, how can I turn it on and off?
> Is there a place I can test only this rule?

There is no particular rule, but other rules depend on information
derived from parsed Trace Information. The best check to see if
SpamAssassin properly parsed your Received header fields is to
enable 'received-header' and 'metadata' debug areas, e.g.:

$ spamassassin -D received-header,metadata <test.msg

and see if parsed fields came out correctly.



But above all: when generating a Received header field, follow
the RFC precisely! Do not copycat samples from some other MTA,
it may not be correct. There are just too many mailers generating
nonstandard or just broken Received header fields, causing headaches
and requiring dealing with exceptions in software trying to parse it!

Mark

SpamAssassin users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.