Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities

[Scott Kitterman <[e-mail]>]

On Tuesday, March 13, 2012 01:30:21 AM S Moonesamy wrote:
> At 05:27 10-02-2012, spfbis issue tracker wrote:
> >#12: RFC 4408 Section 9 - Forwarding and helo identities
> >
> >  Message from Alessandro Vesely on 10 Feb 2012:
> >  
> >  The advice given in the non-normative Section 9 is misleading.  On the
> >  one hand, it provides overly cumbersome techniques based on macros
> >  that are not universally considered safe.  On the other hand, it fails
> >  to state the obvious point that a return-path is only needed if
> >  someone is going to care about delivery failures.

It is a given that one only need care about return-path being accurate if one 
cares about delivery failures, but also irrelevant.  Random dropping of email 
(either original messages or bounces) interferes with the overall reliability 
of email on the internet.  I don't think the group should add anything 
indicating that discarding bounces or directing mail from to a non-existant 
mailbox because the sender doesn't care is a good idea.   -1 on the concept.

More detailed comments below.

> >  When an email alias refers to an external domain, the forwarder must
> >  change it.  This has to be normative, and update Section 3.9.1 of
> >  [RFC5321] --not one of the best written sections of that paper.
> >  
> >  Forwarding à la MAIL FROM:<> should be mentioned as the default,
> >  easiest way to re-inject messages.  The implied interoperability is
> >  that the owner of the target mailbox must be aware of a given
> >  "forwarding recipe", and be able to modify or delete it.  The
> >  variation MAIL FROM:<[e-mail]> is necessary when a
> >  postmaster's action is needed for modifying/deleting a given recipe.
> >  SRS should be mentioned as a general purpose variation for extended
> >  forwarding needs.
> >  
> >  The spec should say that an SPF record must be defined for every A or
> >  AAAA record, irrespectively of whether its host label also appears in
> >  some MX RRs.  We should encourage the use of _spf labels and
> >  redirect= for designing sound and maintainable SPF compliance.

This issue encompasses a number of disparate recommendations and Alessandro 
has a number of comments that relate to different parts of the section.  I 
think it's useful to talk about each part in turn:

   9. Implications
      9.1. Sending Domains

> >  The advice given in the non-normative Section 9 is misleading.  On the
> >  one hand, it provides overly cumbersome techniques based on macros
> >  that are not universally considered safe.  

This appears to refer to 9.1.  

Nothing is "universally considered safe".  It's a known fact that drinking too 
much water can kill you.  That doesn't make drinking water a bad idea.  It is 
true that the type of record suggested in 9.1 is uncachable, so domains that 
use it should be prepared for more DNS traffic than is usual for an SPF record 
that doens't use uncachable macros.  I think it would be reasonable to mention 
this.

Additionally, there are mechanisms that exist today that did not exist when 
RFC 4408 was drafted that provide alternative mechanisms to collect the 
relevant data.  draft-ietf-marf-spf-reporting, currently in IETF wide last 
call, is one mechanism that can support exactly this use case.  Outside the 
IETF, DMARC (dmarc.org) is another approach.  

References to at least draft-ietf-marf-spf-reporting should be added to 9.1, 
but the current text about a special SPF record should remain.  The advantage 
of the special SPF record/DNS log approach is that it requires no cooperation 
from receivers beyond doing normal SPF checks.

      9.2. Mailing Lists

It does not appear that any of the comments address 9.2.  I think it would be 
useful (and a good preamble to the forwarding discussion) to update this text 
to make use of the email architecture terminology that didn't exist when RFC 
4408 was written.  The references should be updated as well.  I don't think 
any functional changes to 9.2 are needed.

      9.3. Forwarding Services and Aliases 

This comment appears to relate to 9.3:

> >  When an email alias refers to an external domain, the forwarder must
> >  change it.  This has to be normative, and update Section 3.9.1 of
> >  [RFC5321] --not one of the best written sections of that paper.

As does:

> >  Forwarding à la MAIL FROM:<> should be mentioned as the default,
> >  easiest way to re-inject messages.  The implied interoperability is
> >  that the owner of the target mailbox must be aware of a given
> >  "forwarding recipe", and be able to modify or delete it.  The
> >  variation MAIL FROM:<[e-mail]> is necessary when a
> >  postmaster's action is needed for modifying/deleting a given recipe.
> >  SRS should be mentioned as a general purpose variation for extended
> >  forwarding needs.

I disagree with the comments.  First, I think 3.6.2 of RFC 5321 is more 
relevant (it even mentions SPF by name).  I don't think 4408bis should update 
5321.  I think it would make consensus substantially harder to achieve and 
there is no technical need for it.

In email architecture terms, a forwarder ("relay SMTP server" in RFC 5321 
terms, not an alias expander) is part of the receiving ADMD.  Forwarding is 
configured by the receiver for the receiver's convenience (unlike mailing lists 
where there is a joint participation model).

It would be useful to explicitly say in this section that THE place to do SPF 
checks is at the transition point between the sending ADMD and the receiving 
ADMD.  When a message is relayed within the recieving ADMD, SPF checks, per se 
are not appropriate, all that can be done is to use the results of checks done 
on the ADMD border if they can be trasmitted in a reasonably trustworthy 
manner.

There are lots of ways problems in this area can be addreesed, a couple are:

1.  Check at the border and internal relays whitelist border relays from SPF 
checks

2.  Rewrite Mail From (e.g. SRS) when mail is transmitted between external and 
internal parts of the ADMD so the check can validate that the mail 
legitimately came a trusted part of their ADMD.

Doing wild tricks like null mail from forwarding are not appropriate here.  
They will result in mail loss and there's no need.

In the terms that 9.3 is written, I think this is mostly a middle/end problem, 
but the methods listed for beginning/middle/end that are listed are all 
potentially useful.  This could use some cleanup to use email arch terms and 
such, but it's a pretty decent list of options to use.

      9.4. Mail Services 
      9.5. MTA Relays 

It doesn't appear that there are parts if this issue related to the last two 
sub-sections.

> >  The spec should say that an SPF record must be defined for every A or
> >  AAAA record, irrespectively of whether its host label also appears in
> >  some MX RRs.  We should encourage the use of _spf labels and
> >  redirect= for designing sound and maintainable SPF compliance.

I think it would be useful to add something in this section that addresses 
domains that send no mail.  For hosts that really send no mail, "v=spf1 -all" 
is a great record to be publishing as it's got a zero percent chance of false 
positive.  I think SHOULD publish for all domains is plenty.  I don't see a 
MUST.

redirect/include and _spf are nice tools for domains that need them.  They are 
not, however, a general solution or requirement.  I think 5.2 already give 
adequate coverage to the use of include:.  I think it would be useful (as part 
of the processing limits discussion) to include an indication that SPF records 
SHOULD NOT require TCP fallback to retrieve (and this includes the answers for 
other TXT records published for that domain) and offer the _spf example of how 
to work around packet size limitations.

Scott K