headers
Frank Ellermann | 1 Mar 02:48
Picon
Picon

Re: MTS transparency and anonymity


Tony Finch wrote:

> my point is that if the message is rejected a bounce will be
> created, which is likely to be collateral spam.

Yes.  And RfC 3834 replies, all "legacy" auto-responders, and
all broken-by-design C/R-systems cause more "collateral spam".

The essence of this problem is "bounces-to" versus "source" as
in <http://article.gmane.org/gmane.mail.spam.spf.discuss:14678>

                    Sigh, Frank
Permalink | Reply | 2 comments |
headers
Keith Moore | 1 Mar 06:48
Picon

Re: MTS transparency and anonymity


>> my point is that if the message is rejected a bounce will be
>> created, which is likely to be collateral spam.
>
> Yes.  And RfC 3834 replies, all "legacy" auto-responders, and
> all broken-by-design C/R-systems cause more "collateral spam".

until someone figures out a reliable way to distinguish spam from 
legitimate mail, any auto-responder is going to create some collateral 
spam.  there's no way around that.  RFC 3834 does expect responders to 
decide whether or not it's appropriate to respond to a message.

> The essence of this problem is "bounces-to" versus "source" as
> in <http://article.gmane.org/gmane.mail.spam.spf.discuss:14678>

no that's not the essence of the problem.  and fwiw, you're wrong about 
something you said in that article, in particular this:

> It's extremely important to understand, that the MAIL FROM
> address is not only some potentially unrelated Errors-To
> address, it is THE source, THE sender, THE originator.

MAIL FROM is fundamentally the address where bounces go.  It is NOT 
necessarily any of the source, the sender, or the originator.  There 
are and always have been valid reasons for MAIL FROM to be set to some 
other address than the source/sender/originator.

...and it's extremely important that you understand this.

Keith
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hector Santos | 1 Mar 05:31
Favicon

Re: MTS transparency and anonymity


----- Original Message -----
From: "Tony Finch" <dot <at> dotat.at>
To: "Keith Moore" <moore <at> cs.utk.edu>
Cc: <blilly <at> erols.com>; <ietf-822 <at> imc.org>
Sent: Monday, February 28, 2005 1:50 PM
Subject: Re: MTS transparency and anonymity

>
> > > We've found that SMTP call-back return path verification is quite
> > > effective, though it has very nasty behaviour for the victims of joe
jobs.
> >
> > I have somewhat different experience - I've found that SMTP call-back
> > verification often produces unnecessary failures, as it's not unusual
for
> > the sender's SMTP server to fail to respond promptly even though the
> > message is legitimate.
>
> Oh yes, I didn't say it was easy to use and without interop problems :-)
> But they can be mitigated with judicious use of exemption lists etc.

In practice, it is very effective simply because the fact is  60-80% of the
transactions are forged or problematic.  It will undoubted catch a very
signficant portion these exact real "failure" points.

The implementation should use a non-permanent 45x response code to allow a
remote system to retry.

However, as it been proven in practice, as also illustrated with the growth
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Ellermann | 1 Mar 09:22
Picon
Picon

Re: MTS transparency and anonymity


Keith Moore wrote:

> any auto-responder is going to create some collateral spam.
> there's no way around that.

If enough forgeries are rejected before they can hit their
victims incl. auto-responders, then the spammers will use
other addresses in their reverse paths.  And then it would
be again "some damage" instead of the "huge damage" today.

If that's impossible the huge damage would force users to
delete anything which might be "collateral spam" without
manually checking it, and that would be the end of SMTP as
we know it.

 [bounces-to vs. sender] 
> that's not the essence of the problem.

IBTD, and after Bruce mentioned RfC 733 here I looked into
it.  It's the same concept of sender as in STD 10:  "a MAIL
command indicating the sender of the mail", "a reverse-path,
which specifies who the mail is from".

> MAIL FROM is fundamentally the address where bounces go.  It
> is NOT necessarily any of the source, the sender, or the
> originator.

You need another net or another way to transport mail before
the 1st Internet MTA for differences.  MAIL FROM is what the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bruce Lilly | 1 Mar 14:24
Picon

Re: MTS transparency and anonymity


On Mon February 28 2005 08:07, Charles Lindsey wrote:

> So we can consider how those requirements are met in the 4 cases:
> 
> 
>                 1. No From      2. blah.invalid 3. @[]          4. From <>
> 
> A. delivery     98% [1]         100%            98%             98%
[...]
> Clearly, this analysis shows that no solution is going to be perfect (but
> we knew that already). OTOH, it does seem to shown that #1 has worse
> problems than the others.

What it shows is that you can start from preconceived notions,
make up a bunch of random numbers unrelated to any sort of
testing or scientific basis, then say "See, it shows I was right".

Bollocks.
Permalink | Reply | 2 comments |
headers
Hector Santos | 1 Mar 15:16
Favicon

Re: Site policy vs. HELO


Typo Fix:

----- Original Message -----
From: "Hector Santos" <winserver.support <at> winserver.com>
To: "ietf-822" <ietf-822 <at> imc.org>; "Vince Sabio" <vince <at> vjs.org>
Sent: Tuesday, March 01, 2005 9:08 AM
Subject: Re: Site policy vs. HELO

> Vince,
>
> I would think section 7.7 inherently implies HELO to be included when it
> mentioned "EHLO." It might be a slip in not including HELO along with
EHLO.
> I think the principle idea was about site policy rejection code
> recommendation and using a 55x response code.
>
> The fallback response code is 50x which is the class of "unknown command"
> response codes. This is what you would normally expect for a non-ESMTP
host
> site who does not support or recognize HELO. See section 4.2.4 about 502
vs.
> 500.
>

I meant "....who does not support or recognize EHLO."

Sincerely,

Hector Santos, CTO
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hector Santos | 1 Mar 15:08
Favicon

Re: Site policy vs. HELO


Vince,

I would think section 7.7 inherently implies HELO to be included when it
mentioned "EHLO." It might be a slip in not including HELO along with EHLO.
I think the principle idea was about site policy rejection code
recommendation and using a 55x response code.

The fallback response code is 50x which is the class of "unknown command"
response codes. This is what you would normally expect for a non-ESMTP host
site who does not support or recognize HELO. See section 4.2.4 about 502 vs.
500.

For example:

The ESMTP compliant sender will issue an EHLO and generally, you can get a
clue by looking for "ESMTP" as part of the standard welcome line (BCP), but
this is not reliable.  So the ESMTP client should always try EHLO first.

S: 250 %hostdomain%, %ProductName% ESMTP server %version% ready.
C: EHLO xxxxx
S: 500 Unrecognized command: EHLO

This is when you should fall back when a 50x is received.  You should not
fall back for a 55x response which is what 7.7 is basically saying, and I
believe that includes a 55x response to HELO as well per the site policy.

PS: A 55x response to HELO/EHLO is a growing practice.  It kills a
significant amount of bulk spammers specially thus who pipe line the
transaction. Simply add a strict SMTP compliancy and you will catch much of
(Continue reading)

Permalink | Reply | 1 comment |
headers
Keith Moore | 1 Mar 20:16
Picon

Re: MTS transparency and anonymity


> Now, the issue is what here?

timing hazards.  client A talks to server B, server B talks to server C,
which is the MX for the originator's email address.

if server C doesn't respond until near the end of server B's timeout
(due to server load or network congestion or whatever), server B
will give up.  when client A retries, often (in my experience) the same 
thing happens again.  that is, a lot of the times the delays aren't
randomly scattered (which would be recoverable) but are clustered for
certian sender addresses.

SMTP as currently specified wasn't designed to handle real-time 
callbacks.  for instance, there is a single set of timeout limits
for all servers.

> This is why it works for thousands of our installations with many HAPPY
> faces and little to know false positives.

most of my thousands of users had no complaints. but a few were extremely
unhappy, to say the least, when their mail stopped working.

my situation is probably different than yours.  I run a server which
provides two services to its users: mail forwarding and delivery of a
moderated weekly digest.  the callbacks were used to filter out spam 
and viruses from mail sent to forwarding addresses, from digest 
messages, and from service requests.  the users are scattered all over
the world, mostly in academic institutions, but some have better 
connectivity than others.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bruce Lilly | 2 Mar 17:49
Picon

Update to "simplified" RFC 2822 grammar


I have made some fairly minor changes to the "simplified"
RFC 2822 grammar at
http://users.erols.com/blilly/mparse/rfc2822grammar_simplified.txt

1. added some lines/characters to support parsing/formatting
   by an ABNF formatter (http://users.erols.com/formatting/abnff)

2. the formatter found a few errors (3 or 4 extraneous right
   parentheses, and an obs-comments alternative incorrectly
   labelled comments; these have been fixed
Permalink | Reply | 2 comments |
headers
Charles Lindsey | 2 Mar 16:04
Picon
Picon

Re: MTS transparency and anonymity


In <200503010824.24367.blilly <at> erols.com> Bruce Lilly <blilly <at> erols.com> writes:

>On Mon February 28 2005 08:07, Charles Lindsey wrote:

>> So we can consider how those requirements are met in the 4 cases:
>> 
>> 
>>                 1. No From      2. blah.invalid 3. @[]          4. From <>
>> 
>> A. delivery     98% [1]         100%            98%             98%
>[...]
>> Clearly, this analysis shows that no solution is going to be perfect (but
>> we knew that already). OTOH, it does seem to shown that #1 has worse
>> problems than the others.

>What it shows is that you can start from preconceived notions,
>make up a bunch of random numbers unrelated to any sort of
>testing or scientific basis, then say "See, it shows I was right".

>Bollocks.

There speaks a man whose mind is made up, and who does not wish to be
confused by the facts.

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl <at> clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
(Continue reading)

Permalink | Reply | 1 comment |

Gmane