headers
SM | 1 May 2007 01:29

Re: Recap Issues 0b/21/25


At 23:09 29-04-2007, Frank Ellermann wrote:
>Whether those references are added or not, I still think the general
>SMTP model has to be "tuned" for this millennium.  All the "MUST NOT
>reject" should be toned down (or removed if the problem they tried to

We should also consider the legacy systems out there.  A complete 
reversal to reject, no bounces, makes the model 
unreliable.  Currently, the sender assumes that the mail has been 
delivered if they didn't get a bounce.  If we push too strongly for a 
"no bounce" approach, we'll be creating blackholes.

>But there's only one place for the receiving side to decide this, at
>the border MTA.  Later is too late, it can cause bounces to innocent
>bystanders, or - if the mail is dropped - it loses legit mail (in
>the case of a "false positive").

Sometimes the "border" is not clear-cut, i.e. the mail may go through 
several hops before reaching a MTA which can decide whether delivery 
will be successful or not.

I read:

    "[add REFERENCES here], has been done in providing ways to
     ascertain that an address is valid or belongs to the person who
     actually sent the message. A server MAY attempt to verify the return
     path before using its address for delivery notifications, but"

as a push towards SPF and CBV.  CBV looks like a way to get around 
the fact that most mail serves have VRFY disabled.  Under certain
(Continue reading)

Permalink | Reply | 3 comments |
headers
SM | 1 May 2007 01:34

Re: new issue: non-2606 domains


At 06:27 30-04-2007, Arnt Gulbrandsen wrote:

>Some examples use non-2606 domains.
>
>I suggest the following general replacements, which seem to make all 
>the examples and text conflict-free:

[snip]

>physics.foo-u.edut -> physics.example.edu

example.edu is not covered by RFC 2606.  It is however assigned to IANA.

>There's also an occurence of isi.edu, but I cannot bring myself to 
>suggest removing Jon Postel's email address from 821ter ;)

Me neither. :)

Regards,
-sm
Permalink | Reply | 1 comment |
headers
John C Klensin | 1 May 2007 01:42

Re: "for" clause on Received: header field


--On Monday, 30 April, 2007 18:05 -0400 "Robert A. Rosenberg"
<hal9001 <at> panix.com> wrote:

> 
> At 09:45 -0700 on 04/30/2007, ned+ietf-smtp <at> mrochek.com wrote
> about Re: "for" clause on Received: header field:
> 
>> The problem I see with the matching approach, aside from the
>> obious overhead, is while you can assume that a successful
>> match to, say, a To: field means it is OK to expose that
>> recipient address in a for clause, not finding  any matches
>> doesn't mean the address has bcc semantics. So you end up
>> presenting  the subset
>> of the active recipient list that happen not to have been
>> transformed by forwarding/routing activites in ways that
>> prevent matching. The result makes for clause disppear in
>> prcecisely the cases where it is most useful for debugging
>> purposes: When transformation of the recipient addresses by
>> forwarding/routing has led to a mismatch between what's in
>> the header and what's in the envelope.

> The solution to the matching issue is simple. If you are the
> ultimate receiver domain (ie: Example.com for mail addressed
> to * <at> example.com), just clone the message so there is a
> separate copy for each Rcpt-To address and place the
> appropriate address into the for clause of each cloned message
> - IOW: Act as a SMTP Server that is designed to not group
> multiple Rcpt-To commands into an outgoing email message even
> though the Mail-To's point at the same MX Server.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Ellermann | 1 May 2007 01:37
Picon
Picon

Re: rfc2821bis-03 Issue 25: Re: Recap Issues 0b/21/25


John Leslie wrote:

> There's actually some rather good work towards that, called BATV:
> http://www.mipassoc.org/batv/

> which enables the use of a MailFrom which cannot be delivered to
> the "sender" unless it passes some checks by the "originating"
> mailserver.

BATV is rather tricky if you intend to send via unrelated routes
(different MONs in Keith's terminology) directing error reports
to one "originating" MRN.  If that's no issue BATV should reject
most unsolicited auto-responses (anything mentioned in RFC 3834 +
DSNs + MDNs) at the alleged originator.

For that point I'd say SPF can aggregate unrelated MONs on demand,
but it's difficult with BATV.  On the other hand BATV works for
almost all unsolicited auto-responses no matter what the bad guys
or the receivers do, while SPF depends on at least some receivers
supporting it, and that the bad guys not being sure who checks SPF
stay away from FAIL-protected addresses.

Both techniques can be combined as desired.  One disadvantage of
BATV is that it doesn't catch all forged Return-Paths (as SPF
FAIL does it when used), it only eliminates backscatter arriving
at the alleged sender in the form of bounces and auto-responses.

Before the spammers decided to stay away from my FAIL-protected
addresses (that took them some months in 2004, maybe the release
(Continue reading)

Permalink | Reply | 0 comments |
headers
John C Klensin | 1 May 2007 01:55

Re: rfc2821bis-03 Issue 34: non-2606 domains


--On Tuesday, 01 May, 2007 00:27 +0200 Frank Ellermann
<nobody <at> xyzzy.claranet.de> wrote:

> My consideration is that I don't know the owner of foo.com and
> can't tell if he likes that addresses in his domain are used in
> 2821.  And if he likes it I'd wonder if 2821 is a good place
> for foo.com search engine optimization.

Sure.  And, as I indicated in another note (possibly not to the
list), I have no problem at all with the IESG, or someone else,
insisting on the use of 2060 names in new documents.  But, for
those that have been using other names for a decade or two, and
the names they have been using,

(i) if the holder of foo.com doesn't like the impact of having
that domain used in examples, they presumably have gotten used
to it a long time ago... and the first of those examples
preceded their registration.   In particular, I suggest that
having such a domain for email may constitute holding up a
"spammers, especially dumb spammers, please hit me" sign,
especially if the mailboxes used in those examples actually
exist.

(ii) anyone who picks up those examples and uses them unchanged
to run or test something is sufficiently stupid that they
probably deserve to encounter what you politely describe as
search engine optimization.

(iii) the "search engine optimization" problem exists for http
(Continue reading)

Permalink | Reply | 1 comment |
headers
David F. Skoll | 1 May 2007 02:57
Favicon

Re: Recap Issues 0b/21/25


Robert A. Rosenberg wrote:

> Query - Why not in an "Unable to Report to the Return Path" situation,
> just route the Notification Message to a Role Account address on the
> Server instead of (or in addition to) Logging?

That's fine.  It's the default for Sendmail.  It's also one of the
first things I change when I install Sendmail for anyone who does any
reasonable amount of mail.  Otherwise, the role account simply gets
inundated.

I think any mechanism that makes it easy for an operator to quickly figure
out what happened after the fact is acceptable, whether that's by reading
the archived role account mail or running a script on a log file.

The point is, I don't think we should lightly abandon NDNs, and
certainly not without at least mentioning steps that should be taken
by a responsible SMTP implementation to mitigate the damage.

Regards,

David.
Permalink | Reply | 0 comments |
headers
Frank Ellermann | 1 May 2007 04:16
Picon
Picon

Re: rfc2821bis-03 Issue 34: non-2606 domains


John C Klensin wrote:

> the issue now is, IMO, about a cosmetic change.

Okay, I promise to be silent if this particular
nit runs into any IESG [Discuss] roadblocks... :-)
Permalink | Reply | 0 comments |
headers
Frank Ellermann | 1 May 2007 05:12
Picon
Picon

Re: Recap Issues 0b/21/25


SM wrote:

> We should also consider the legacy systems out there. A complete
> reversal to reject, no bounces, makes the model unreliable.

+1  We're not going to copy the SpamCop FAQ wholesale into 2821bis.
( Nevertheless I've invited the SpamCop newsgroup readers to chime
  in, some have rather radical ideas compared with what we say. :-)

> If we push too strongly for a "no bounce" approach, we'll be
> creating blackholes.

Yes, there's a similar situation in NetNews, if you go too far in
attempts to avoid "dupes" (articles arriving more than once) you
get "nopes" (articles arriving less than once), and for obvious
reasons I always considered "nopes" as worse than "dupes".

> Sometimes the "border" is not clear-cut, i.e. the mail may go
> through several hops before reaching a MTA which can decide
> whether delivery will be successful or not.

The border is defined by query=mx, and among the mailers acting
as MX the first getting mail from another mailer is "the border".

That's what I think how "border" could be defined, ignoring some
corner cases like "no MX" or all definitions of "local mail" if
it touches an MX.

> I read:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Arnt Gulbrandsen | 1 May 2007 08:49
Favicon

Re: new issue: non-2606 domains


sm <at> resistor.net writes:
> example.edu is not covered by RFC 2606.  It is however assigned to IANA.

I saw that, and assumed it was overlooked.

Arnt
Permalink | Reply | 0 comments |
headers
SM | 1 May 2007 09:06

Re: Recap Issues 0b/21/25


At 20:12 30-04-2007, Frank Ellermann wrote:
>Yes, there's a similar situation in NetNews, if you go too far in
>attempts to avoid "dupes" (articles arriving more than once) you
>get "nopes" (articles arriving less than once), and for obvious
>reasons I always considered "nopes" as worse than "dupes".

Then you understand the problem.

>The border is defined by query=mx, and among the mailers acting
>as MX the first getting mail from another mailer is "the border".

The MX is not always the "border".

>That's what I think how "border" could be defined, ignoring some
>corner cases like "no MX" or all definitions of "local mail" if
>it touches an MX.

I'm not thinking of "no MX" here.  It may not always be possible to 
do recipient validation at "the border" you mentioned.  But we can 
encourage people to do the policy filtering there and reject if they 
see fit.  This in itself may decrease the number of bounces significantly.

>I think CBV isn't specified in any RFC, and so we can't add a
>reference to it.  Similarly there's no RFC for grey-listing,
>SRS, SES, CSV, or BATV.  Referencing RFC 4409 chapter 6.1 should
>be okay.  For 4408 I'm not "neutral" (4409-1=4408 is nice :-)
>Maybe one example 4409 6.1 is enough.

CBV is easily turned on in one well-known MTA and people will flip
(Continue reading)

Permalink | Reply | 0 comments |

Gmane