How do you deal with mail from <>?
c...@arizona.edu
>domains with a return address of <>.
We accept it.
>In the RFC, it states to accept all of that email,
And that's why. :)
> but I get too much spam
>from people using that return address.
I'm doing various filtering on other parts of the message, so some of these
messages do in fact get sidelined, but it's not because of the <> address.
-C
---
Chris De Young c...@arizona.edu
Dan Wing
> domains with a return address of <>.
>
> from people using that return address.
All bounces have a MAIL FROM of <>, so if you refuse it, you're
causing mail to be irretrievably lost if one of your users mistypes
a To or CC address, or sends mail to someone who has had their
account terminated.
> What I would like to see an example of is a rule in smtp_Server_reject. to
> redirect all mail from <> to postm...@xxx.com, where xxx.com is my domain.
>
> This way, I could deal with bounces and delete the spam.
I'm pretty sure you can now do this sort of thing with the rewrite
rules.
-d
Bob Koehler
>
> All bounces have a MAIL FROM of <>, so if you refuse it, you're
> causing mail to be irretrievably lost if one of your users mistypes
> a To or CC address, or sends mail to someone who has had their
> account terminated.
Like I said, we don't specifically allow it. We have not lost any
bounces because of this.
Hunter Goatley
> > I'm wondering what other people are doing with mail coming into their
> > domains with a return address of <>.
> >
> > In the RFC, it states to accept all of that email, but I get too much spam
> > from people using that return address.
> Somewhere in the Multinet documentation or sample files someone put
> a blurb about how the RFC claims all systems should accept <>, but
> it's actually a relay hole. I simply follow that advaice and don't
> specifically allow mail with return address of <>.
Then you're blocking all delivery notification messages. As far as I
can tell, it's true that the RFC doesn't require you to accept those.
However, the RFCs (RFC1123, in particular) do require that delivery
failure messages must be sent using a null return path:
If there is a delivery failure after acceptance of a message,
the receiver-SMTP MUST formulate and mail a notification
message. This notification MUST be sent using a null ("<>")
reverse path in the envelope; see Section 3.6 of RFC-821. The
recipient of this notification SHOULD be the address from the
envelope return path (or the Return-Path: line). However, if
this address is null ("<>"), the receiver-SMTP MUST NOT send a
notification. If the address is an explicit source route, it
SHOULD be stripped down to its final hop.
The confusion may arise from this (also from RFC1123):
5.2.9 Command Syntax: RFC-821 Section 4.1.2
The syntax shown in RFC-821 for the MAIL FROM: command omits
the case of an empty path: "MAIL FROM: <>" (see RFC-821 Page
15). An empty reverse path MUST be supported.
The server must support receiving mail from <>, but it doesn't say
anything about what should be done with it.
But if you modify your reject rules to reject anything from <>, you
are blocking all messages about delivery failures, which is probably
not a good thing.
As far as it being a relay hole, it is often exploited by those
looking for a relay, which is why other methods must be employed to
block the relays (such as those suggested in the template reject file
supplied with MultiNet).
Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
<goath...@GOATLEY.COM> http://www.goatley.com/hunter/
New Robert McCammon novel and site: http://www.RobertRMcCammon.com/
Jeff Schreiber
>
>In article <0D3123022EB2D411BCBC...@poster.callan.com>, "Kattalia, Mark" <katt...@callan.com> writes:
>> I'm wondering what other people are doing with mail coming into their
>> domains with a return address of <>.
>>
>> In the RFC, it states to accept all of that email, but I get too much spam
>> from people using that return address.
>
> Somewhere in the Multinet documentation or sample files someone put
> a blurb about how the RFC claims all systems should accept <>, but
> it's actually a relay hole. I simply follow that advaice and don't
> specifically allow mail with return address of <>.
>
Multinet originally allowed anything with a mail from of <>, which
bypassed the filter file. That was changed and you are now allowed
to specify rules with <> in them. One of the things you can do is
blindly accept mails from <> to resort back to the original behavior.
However the problem was that there was relay tests that Multinet would
fail for, because the mail would be a relay destination, but would have
<> as the from and it would cause it to skip the filtering.
As long as you have your relay filtering setup correctly, relay attempts
with <> as the mail from will still get caught, and other null mail
froms will get delivered to the local users.
-Jeff
Dan Wing
> > from people using that return address.
>
> Somewhere in the Multinet documentation or sample files someone put
> a blurb about how the RFC claims all systems should accept <>, but
> it's actually a relay hole.
That blurb isn't accurate.
-d
Dan Wing
Huh. Send mail to dan...@cisco.com -- do you get a bounce? Our
bounces have a null MAIL FROM, as required by the relevant RFCs.
-d
Jeff Schreiber
>
>In article <0D3123022EB2D411BCBC...@poster.callan.com>, "Kattalia, Mark" <katt...@callan.com> writes:
>> I'm wondering what other people are doing with mail coming into their
>> domains with a return address of <>.
>>
>> from people using that return address.
>
> Somewhere in the Multinet documentation or sample files someone put
> a blurb about how the RFC claims all systems should accept <>, but
> specifically allow mail with return address of <>.
>
Ok... I think your referring to:
! Accept all messages with MAIL FROM:<> (bounce messages)
! This rule is commented out because you probably don't want it, although
! We're _supposed_ to always accept it. This is the main method relay attacks
! use, by always saying they are from <> to take advantage of that RFC hole.
!
! <> * * n
In the SMTP_SERVER_REJECT.TEMPLATE.
Let me explain, and perhaps I need to edit that a little better.
Originally multinet let MAIL FROM:<> through without filtering. This
became a problem as lots of relay attempts were taking advantage of
that hole.
The change was to let the MAIL FROM:<> to go through the filtering as
would any e-mail message. The commented out rule was so allow the
customer to take it back to the old behavior if they wanted.
The changes to the rules don't change, it just lets the MAIL FROM:<> to
go through the same relay checks as regular mail. If you follow through
the reject template, you'll see that the <> will be checked in all the
rules that have "*" for the MAIL FROM. Also you will see that there is
a line[s] for the internal networks to be able to bounce mail out, as
the filter template makes checks to make sure the mail from's on internally
generated messages have emails for the local domain [e.g. blocking
forgery attempts from internal sources]. Because of that rule, you also
need to allow <> to get through as well.
So the "comment" was just to explain the commented out global accept for
MAIL FROM:<>, explaining how to get back to the old behavior.
-Jeff
--
Jeff Schreiber Principal Software Engineer Process Software LLC
schr...@mx.process.com http://www.process.com
TCPware, MultiNet & PMDF: Stronger than Ever
Bob Koehler
OK, after studying Jeff Schreiber's post I think the relavent info
is that we don't block it, but we don't SPECIFICALLY allow it, that
is the line in smtp_server_reject which would allow ALL mail from <>
is commented out:
! <> * * n
But, yes it does work after passing through all our other filters:
Return-Path: <>
Received: from sj-msg-core-4.cisco.com ([171.71.163.54]) by
<node>.<domain>
with SMTP for koehler@<node>.<domain>;
Thu, 25 Jul 2002 8:23:20 -0400
Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com
[171.69.24.12])
by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id
g6PCNJqK021208
for <koehler@<node>.<domain>>; Thu, 25 Jul 2002 05:23:19 -0700
(PDT)
Received: from localhost (localhost)
by sj-msg-av-2.cisco.com (8.12.2/8.12.2) id g6PCNJpe025304;
Thu, 25 Jul 2002 05:23:19 -0700 (PDT)
Date: Thu, 25 Jul 2002 05:23:19 -0700 (PDT)
From: Mail Delivery Subsystem <MAILER...@sj-msg-av-2.cisco.com>
Message-Id: <200207251223....@sj-msg-av-2.cisco.com>
To: <koehler@<node>.<domain>>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="g6PCNJpe025304.1027599799/sj-msg-av-2.cisco.com"
Subject: Returned mail: see transcript for details
Auto-Submitted: auto-generated (failure)
This is a MIME-encapsulated message
--g6PCNJpe025304.1027599799/sj-msg-av-2.cisco.com
The original message was received at Thu, 25 Jul 2002 05:23:18 -0700
(PDT)
from localhost [127.0.0.1]
----- The following addresses had permanent fatal errors -----
<dan...@sj-av.cisco.com>
(reason: 550 5.1.1 <dan...@sj-av.cisco.com>... User unknown)
----- Transcript of session follows -----
... while talking to sj-msg-core-4.cisco.com.:
>>> DATA
<<< 550 5.1.1 <dan...@sj-av.cisco.com>... User unknown
550 5.1.1 <dan...@sj-av.cisco.com>... User unknown
<<< 503 5.0.0 Need RCPT (recipient)
--g6PCNJpe025304.1027599799/sj-msg-av-2.cisco.com
Content-Type: message/delivery-status
Reporting-MTA: dns; sj-msg-av-2.cisco.com
Received-From-MTA: DNS; localhost
Arrival-Date: Thu, 25 Jul 2002 05:23:18 -0700 (PDT)
Final-Recipient: RFC822; dan...@sj-av.cisco.com
Action: failed
Status: 5.1.1
Remote-MTA: DNS; sj-msg-core-4.cisco.com
Diagnostic-Code: SMTP; 550 5.1.1 <dan...@sj-av.cisco.com>... User
unknown
Last-Attempt-Date: Thu, 25 Jul 2002 05:23:19 -0700 (PDT)
--g6PCNJpe025304.1027599799/sj-msg-av-2.cisco.com
Content-Type: message/rfc822
Return-Path: <koehler@<node>.<domain>>
Received: from proxy3.cisco.com (localhost [127.0.0.1])
by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g6PCNIpe025296
for <dan...@sj-av.cisco.com>; Thu, 25 Jul 2002 05:23:18 -0700 (PDT)
Received: from <node>.<domain> (<node>.<domain>
[192.225.88.40])
by proxy3.cisco.com (8.12.2/8.11.2) with SMTP id g6PCNHMB004209
for <DAN...@CISCO.COM>; Thu, 25 Jul 2002 05:23:18 -0700 (PDT)
Received: by <node>.<domain> for DAN...@CISCO.COM;
Thu, 25 Jul 2002 8:23:04 -0400
Date: Thu, 25 Jul 2002 8:23:04 -0400
From: Bob Koehler <koehler@<node>.<domain>>
To: dan...@cisco.com
Message-Id: <020725082304.1b03@<node>.<domain>>
Subject: intentional bounce?
Intentional bounce.
Grou: vmsnet.networks.tcp-ip.multinet, Ite: 10000 (Rang: #9939 - #10003,
Unre:5)
Subject: RE: How do you deal with mail from <>?
From: Dan Wing <dw...@cisco.com>,
Info-Multinet<==>vmsnet.networks.tcp-ip.multin
Date: 24 Jul 2002 11:03:41 -0600
-d
----------------------------------------------------------------------
Bob Koehler | Computer Sciences Corporation
NASA GSFC Flight Software | Federal Sector, Civil Group
speaking for no one else | please remove ".aspm" when replying
--g6PCNJpe025304.1027599799/sj-msg-av-2.cisco.com--