Mail, and what where we are.
Bill Harris
Just a quick status on Mail.
It looks like from the increasing traffic load, and from watching
Mail's performance over the last few days since the upgrade, that
we have probably enough headspace to last about 30 days or less.
If we don't move any load off of mail, it's going to start getting
ugly again in about 2 weeks.
We have received the 4 border machines, and are building the new
codebase up to install on these systems. As I mentioned before, the
new software has much stronger filtering capabilities, and it appears
to have better high volume characteristics. It has some weaknesses,
for one, a flat directory queue that will have to be fixed, and a
couple of other items, but these are all doable, and the plan is to
deploy them next week.
Please be advised, the new mail code will be MUCH more strict
about what it will accept, and who it will accept from. Remember,
this is a good thing.
Also, please continue to use "smtp.airmail.net" for your outgoing
mail server. It will help a lot if you will change your OUTGOING
mail server to smtp.airmail.net. If you have questions about how
to do this, please e-mail sup...@airmail.net and they can tell
you what to change in your client.
Once the new border servers are deployed behind the layer 4
switch, we will begin moving significant load ie; all SMTP traffic
thru the four border servers. POP3 traffic will be passed straight
through to mail.airmail.net.
Customer's can help us reduce spam by forwarding FULL headers to
ab...@airmail.net, where we can either deal with the abuser, and/or
block them from sending any further spam. This can help tremendously.
Happy Thanksgiving.
Bill
Brad Felmey
wrote:
>Please be advised, the new mail code will be MUCH more strict
>about what it will accept, and who it will accept from. Remember,
>this is a good thing.
Bill, the wording here is unclear. Do you mean it's going to be pickier
about what *outgoing* mail it accepts, or what incoming mail it accepts?
I really don't want my incoming mail filtered at all, not even SPAM, not
from known-bad domains, not from anything.
--
Brad Felmey
Bill Harris
> >
> >Please be advised, the new mail code will be MUCH more strict
> >about what it will accept, and who it will accept from. Remember,
> >this is a good thing.
> >
> So is this going to be a problem for me? I moderate a
> newsgroup via an airmail account. Am I going to lose incoming posts
> to your filters?
Shouldn't be a problem at all. I assume the email is directed at your
airmail account, which you in turn moderate. That is the normal process.
Bill
Bill Harris
Incoming and outgoing mail will have to meet RFC specs, or it will be rejected.
Ie; invalid or missing From line, invalid or missing Subject line,
non-existent or invalid DNS sending host are the type of qualifications
that we plan to be much more restrictive on.
Another issue, and just prepare for it, is mail sent to "user" instead of
"us...@airmail.net". Most intelligent clients have a default domain
that they will append to a non-compliant address when they see it,
before it's sent to the mail server, ie; Netscape, and IE. Right now,
Mail.airmail.net assumes it's an address in the IADFW.NET or AIRMAIL.NET
namespace. That assumption is about to stop.
Hope that clear things up a bit.
Bill
Brad Felmey wrote:
> On Wed, 22 Nov 2000 10:14:27 -0600, Bill Harris <bi...@airmail.net>
> wrote:
>
> >Please be advised, the new mail code will be MUCH more strict
> >about what it will accept, and who it will accept from. Remember,
> >this is a good thing.
>
David Zeiger
>Another issue, and just prepare for it, is mail sent to "user" instead of
>"us...@airmail.net". Most intelligent clients have a default domain
>that they will append to a non-compliant address when they see it,
>before it's sent to the mail server, ie; Netscape, and IE. Right now,
>Mail.airmail.net assumes it's an address in the IADFW.NET or AIRMAIL.NET
>namespace. That assumption is about to stop.
That oughta make Mr. Lloyd happy at last! (not to mention Abuse
being happy not to get his mail...)
--
David Zeiger dze...@the-institute.net
Whenever I find myself in a difficult situation, I ask myself "What
Would Jesus Do?" The mental image of my opposition being cast into
pits of hellfire for all eternity *is* comforting, but probably not
what the inventors of the phrase had in mind.
Brad Felmey
wrote:
>Incoming and outgoing mail will have to meet RFC specs, or it will be rejected.
>Ie; invalid or missing From line, invalid or missing Subject line,
>non-existent or invalid DNS sending host are the type of qualifications
>that we plan to be much more restrictive on.
Erm, well, I guess I'll just have to start using my own domain for
incoming as well, then. A quick glance at BUGTRAQ, WINE Devel, and
Linux-kernel lists shows plenty of missing subject lines. In fact, mail
received of a personal nature occasionally has missing subject lines as
well.
I understand the outgoing restrictions, but I would really prefer if you
didn't filter my incoming mail. Since it appears you're going to anyway,
I'll just have to stop using my Airmail email. I prefer otherwise, but I
insist on getting *all* my email.
--
Brad Felmey
Su Wadlow
wrote:
>Incoming and outgoing mail will have to meet RFC specs, or it will be rejected.
>Ie; invalid or missing From line, invalid or missing Subject line,
>non-existent or invalid DNS sending host are the type of qualifications
>that we plan to be much more restrictive on.
So you're saying that as long as the From: line in outgoing
mail is RFC compliant the mail will be allowed through?
Just like it is now, it won't be an issue if the From: line doesn't
contain an IA email address?
And I'll have to agree with the other folks about the missing
Subject: line -- I don't really care for this filtering option. I may
have a perfectly legitimate person send me an email without a
subject; most of my family are horribly non-technical and there's
a very high probability that this could happen. Jeez, I might
even do it myself -- I often send myself test messages from
UTD when troubleshooting a user's problem, and I don't always
worry, or even care about what's in the Subject: line. But I
do need the message to go through . . . .
--
Su Wadlow
swa...@utdallas.edu,
If I have to explain, you wouldn't understand . . . . :-)
OverSoul
<F3959249958FA6A3.9684ACC4...@lp.airnews.net>:
>Incoming and outgoing mail will have to meet RFC specs, or it will be
>rejected. Ie; invalid or missing From line, invalid or missing Subject
>line,
So...if a family member or friend sends me an email without a subject, the
email will be rejected? I don't like that idea at all. I think you should
reconsider at least that portion of it. I'd rather put up with "missing
subject" spam emails than to have email from family or friends rejected
because they forgot to type something in the subject line.
Can you allow the users (us) to somehow configure our account so that we
can actually fine tune the filters you are going to use? Those that want
emails with missing subject lines can get them and those that don't can
filter them out.
Also....what would be an example of an "invalid" subject line ("missing"
subject is easy enough to figure out.)
--
OverSoul
Humanity is a school for the Soul...
David Zeiger
>Erm, well, I guess I'll just have to start using my own domain for
>incoming as well, then. A quick glance at BUGTRAQ, WINE Devel, and
>Linux-kernel lists shows plenty of missing subject lines. In fact, mail
>received of a personal nature occasionally has missing subject lines as
>well.
Missing or blank? I'm not sure that they're the same thing.
Jerry
>
> Brad, your right, my wording is not real clear.
>
> Ie; invalid or missing From line, invalid or missing Subject line,
> that we plan to be much more restrictive on.
>
> "us...@airmail.net". Most intelligent clients have a default domain
> that they will append to a non-compliant address when they see it,
> before it's sent to the mail server, ie; Netscape, and IE. Right now,
> Mail.airmail.net assumes it's an address in the IADFW.NET or AIRMAIL.NET
> namespace. That assumption is about to stop.
>
>
> Bill
>
> Brad Felmey wrote:
>
> > wrote:
> >
> > >Please be advised, the new mail code will be MUCH more strict
> > >about what it will accept, and who it will accept from. Remember,
> > >this is a good thing.
> >
> > Bill, the wording here is unclear. Do you mean it's going to be pickier
> > about what *outgoing* mail it accepts, or what incoming mail it accepts?
> > I really don't want my incoming mail filtered at all, not even SPAM, not
> > from known-bad domains, not from anything.
> > --
> > Brad Felmey
I'll throw my $.02 in - I sometimes get e-mails with a 'vacant' subject
line and they're always spam. I've never gotten a legit message without
something for a subject. Any received message with a 'vacant' subject
line goes directly to the trash folder here. As far as the rest of the
RFC requirements, I wouldn't know. I remain open for any ideas of how
to better deal with the spam issues.
--
jer
Robert Jones
> On Wed, 22 Nov 2000 17:54:40 -0600, Brad Felmey <bfe...@airmail.net> wrote:
> >Erm, well, I guess I'll just have to start using my own domain for
> >incoming as well, then. A quick glance at BUGTRAQ, WINE Devel, and
> >Linux-kernel lists shows plenty of missing subject lines. In fact, mail
> >received of a personal nature occasionally has missing subject lines as
> >well.
>
> Missing or blank? I'm not sure that they're the same thing.
That's an interesting point. I receive mail more or less regularly from
someone who *never* enters a subject. If I view the mail in Netscape with
"normal" headers, there is a blank "Subject:" line. However, if I expose all
headers, the "Subject:" line is gone. As in smooth evaporated. Looking at the
whole thing with a text editor reveals that there really *isn't* a subject!
From - Wed Nov 22 19:23:20 2000
Return-Path: <XXXXXX...@netscape.net>
Received: from imo-r13.mail.aol.com from [152.163.225.67] by mail.airmail.net
(/\##/\ Smail3.1.30.16 #30.14) with esmtp for <rjo...@airmail.net> sender:
<XXXXXX...@netscape.net>
id <mP/13ykyy-...@mail.airmail.net>; Wed, 22 Nov 2000 19:15:24 -0600
(CST)
Received: from XXXXXX...@netscape.net
by imo-r13.mx.aol.com (mail_out_v28.33.) id m.ec.3132d9 (16217)
for <rjo...@airmail.net>; Wed, 22 Nov 2000 20:15:20 -0500 (EST)
Received: from netscape.com (aimmail10.aim.aol.com [205.188.144.202]) by
air-in01.mx.aol.com (v77.14) with ESMTP; Wed, 22 Nov 2000 20:15:20 -0500
Date: Wed, 22 Nov 2000 20:15:19 -0500
From: XXXXXX...@netscape.net
To: rjo...@airmail.net
Mime-Version: 1.0
Message-ID: <1B0D7B7B.7E4F...@netscape.net>
X-Mailer: Franklin Webmailer 1.0
Content-Type: text/plain; charset="us-ascii"
X-Airmail-Delivered: Wed, 22 Nov 2000 19:15:29 -0600 (CST)
X-Airmail-Spooled: Wed, 22 Nov 2000 19:15:24 -0600 (CST)
X-Mozilla-Status: 8005
X-Mozilla-Status2: 00000000
X-UIDL: 10463
<body snipped, sender XX'd>
I'm not lobbying against IA's planned filtering (though I hope there is a
daemon in place that tells the sender know why their email was trashed).
Rather, it's simply a comment on the missing/blank header question.
Regards,
Robert
--
Everything ends badly. Otherwise it wouldn't end.
6:21am up 40 days, 47 min, 1 user, load average: 0.01, 0.02, 0.00
Brad Felmey
wrote:
>On Wed, 22 Nov 2000 17:54:40 -0600, Brad Felmey <bfe...@airmail.net> wrote:
>>Erm, well, I guess I'll just have to start using my own domain for
>>incoming as well, then. A quick glance at BUGTRAQ, WINE Devel, and
>>Linux-kernel lists shows plenty of missing subject lines. In fact, mail
>>received of a personal nature occasionally has missing subject lines as
>>well.
>
>Missing or blank? I'm not sure that they're the same thing.
I understand that, but semantics aside my point is that I don't wish my
email to be filtered in any way. This was why I asked earlier about
opt-out. I still feel that opt-out is the proper thing to offer for
those who don't wish their email to be filtered on somebody else's
standards.
--
Brad Felmey
Neil C. Wolfe
mail comes without subject because of lack of a specific subject. I
really wish you would reconsider this area for reject.
David Zeiger
>I understand that, but semantics aside my point is that I don't wish my
>email to be filtered in any way.
I'm not arguing that, I understand your point perfectly well.
My point is that, if IA is going to filter, will the filter actually
reject all the posts that people think it will reject (perhaps
it will, I'm certainly not well-versed enough in the oddities of
Sendmail and its cousins to know for sure...).
OverSoul
<C4F040AB698D1246.88149B58...@lp.airnews.net>:
>My point is that, if IA is going to filter, will the filter actually
>reject all the posts that people think it will reject
I hope someone from IA will clear things up for us a little....and I hope
they are flexible when it comes to deciding what should be filtered.
Bill Harris
Bill
Brad Felmey wrote:
> On 23 Nov 2000 02:56:16 GMT, dze...@the-institute.net (David Zeiger)
> wrote:
>
> >On Wed, 22 Nov 2000 17:54:40 -0600, Brad Felmey <bfe...@airmail.net> wrote:
> >>Erm, well, I guess I'll just have to start using my own domain for
> >>incoming as well, then. A quick glance at BUGTRAQ, WINE Devel, and
> >>Linux-kernel lists shows plenty of missing subject lines. In fact, mail
> >>received of a personal nature occasionally has missing subject lines as
> >>well.
> >
> >Missing or blank? I'm not sure that they're the same thing.
>
> I understand that, but semantics aside my point is that I don't wish my
Bill Harris
any proactive filtering of the Subject: line. That was a brain bit drop on my part when I
put that post together. Sorry about that. Subject lines can be left blank, per the
RFC's.
The only filtering we MAY do, is if we identify a large spam, with a consistent phrase,
that we can block such spam, based on Subject. We do this now, so this would be nothing
new. Nothing would change, this would be a reactive filter, based on an existing
condition.
Typically, an invalid From:, or Envelope header will be the primary targets to protect
against the ENORMOUS amount of spam, that we currently have to accept, and deal
with in a post-processing manner.
Bill
Gordon Burditt
>Ie; invalid or missing From line, invalid or missing Subject line,
>non-existent or invalid DNS sending host are the type of qualifications
>that we plan to be much more restrictive on.
Some examples of header lines that may get your mail (or incoming
mail to you) rejected:
Reply-to: DO NOT REPLY TO THIS MAIL
(no @ in email address)
From: SPAM Forever We Never Unsubscribe Anyone <>
(no @ in email address)
From: hah...@sexyfun.net
(sexyfun.net is a nonexistent domain, plus this particular
return address is used by a recent virus that mails itself
to people on your address list automatically, so it is
specially targeted)
To: <Undisclosed Recipients>
(no @ in email address)
From: us...@airmail.net@airmail.net
(Two @'s in email address)
From: George W. Bush <gwb...@airmmail.net>
(airmmail.net is a nonexistent domain)
To: Al Gore <alg...@aol.com`>
(Note ` character in email address, which makes it a nonexistent domain)
To: Hillary Clinton, 1600 Pennsylvania Avenue, Washington D.C.
(No @ in any of 3 email addresses)
Note that there's nothing in this list about missing,
blank, or obscene Subject: lines (but the AUP still
applies). Also note that this discussion is about MAIL.
It has nothing to do with what you put on the From: line
in NEWS postings, with the caveat that postings to moderated
groups are mailed to the moderator.
Gordon L. Burditt
Brad Felmey
Burditt) wrote:
>Some examples of header lines that may get your mail (or incoming
>mail to you) rejected:
Definitely will be running my own mailserver. Those are ridiculous.
--
Brad Felmey
Daniel Jacobson
>> Incoming and outgoing mail will have to meet RFC specs, or it will be
>> rejected.
>> Ie; invalid or missing From line, invalid or missing Subject line,
>> non-existent or invalid DNS sending host are the type of qualifications
>> that we plan to be much more restrictive on.
> Some examples of header lines that may get your mail (or incoming
> <snip>
> mail to you) rejected:
> To: <Undisclosed Recipients>
> (no @ in email address)
This is how I send to my Tech / Humor mailing list without revealing
everyones Name and E-Mail address. Eudora Pro 3.0.5 and 4.2.2.
Also another method uses just a name without an @ in the To:
Both methods here...
How To Keep All The Addresses From Showing Up In The TO: field
http://wso.williams.edu/~eudora/eudora-use-bcc.html
Anyway...the SPAMers now send UCE with only my address in the To:
field so I not sure about the effectiveness of this one?
--
Over and Out
Daniel Jacobson
James Nuckolls
>On 4 Dec 2000 06:38:52 GMT, gordon...@sneaky.lerctr.org (Gordon
>Burditt) wrote:
>
>>mail to you) rejected:
>
You consider RFC822 "ridiculous?"
James Nuckolls
>In article <7570A17F6415790F.B53F852C...@lp.airnews.net>, gordon...@sneaky.lerctr.org says...
>
>>> rejected.
>>> Ie; invalid or missing From line, invalid or missing Subject line,
>>> non-existent or invalid DNS sending host are the type of qualifications
>>> that we plan to be much more restrictive on.
>
>> Some examples of header lines that may get your mail (or incoming
>> mail to you) rejected:
>> (no @ in email address)
>
> everyones Name and E-Mail address. Eudora Pro 3.0.5 and 4.2.2.
> Also another method uses just a name without an @ in the To:
Depending on how this is done, neither method conforms to RFC822,
which the mail system is *supposed* to be enforcing.
The key is the text between any brackets (< and >), if that's not
a valid email address (read: had an @ sign, and is in a domain
that's valid). With that said, the following form is valid:
To: "Undisclosed Recipients"
This is the form that (appearently) Eudora uses, at least according
to the screen shots in the URL you've posted.
> Anyway...the SPAMers now send UCE with only my address in the To:
> field so I not sure about the effectiveness of this one?
While enforcing the various standards does prevent quite a bit of
spam from being enjected, enforcing standards is not about reducing
spam.
Brad Felmey
>On Mon, 04 Dec 2000 10:19:19 -0600, Brad Felmey <bfe...@airmail.net> wrote:
>>On 4 Dec 2000 06:38:52 GMT, gordon...@sneaky.lerctr.org (Gordon
>>Burditt) wrote:
>>
>>>Some examples of header lines that may get your mail (or incoming
>>>mail to you) rejected:
>>
>>Definitely will be running my own mailserver. Those are ridiculous.
>
>You consider RFC822 "ridiculous?"
Yes.
--
Brad Felmey
Dick Rinewalt
<CF6E822F7726F6C1.2D6B8E3D...@lp.airnews.net>,
James Nuckolls <jam...@iadfw.net> wrote:
> To: "Undisclosed Recipients"
>
> This is the form that (appearently) Eudora uses, at least according
> to the screen shots in the URL you've posted.
Eudora Pro 4.3.3 (and going back several versions I think) uses
To: Recipient List Suppressed:;
James Nuckolls
This method is close enough...
OverSoul ©
<10ADD1BD873ABDFA.E27F9071...@lp.airnews.net>:
> Its been a day, I guess no-one at Airmail cares, or maybe the
>answer is just, "yes, all postings to your group by people using
>non-existant domains will be blocked from your email". I'll start
>working on moving my account.
I've also noticed that IA support seems to be "selectively" responding to
questions here. They answer some while others are ignored. Used to be a
problem in the past, then it got better....now it's getting worse.
The best thing to do is send an email to sup...@airmail.net. They usually
respond pretty quickly that way.
Ron W
>On 4 Dec 2000 19:00:16 GMT, Daniel Jacobson <dani...@iadfw.net> wrote:
>>In article <7570A17F6415790F.B53F852C...@lp.airnews.net>, gordon...@sneaky.lerctr.org says...
>>
>>>> Incoming and outgoing mail will have to meet RFC specs, or it will be
>>>> rejected.
>>>> Ie; invalid or missing From line, invalid or missing Subject line,
>>>> non-existent or invalid DNS sending host are the type of qualifications
>>>> that we plan to be much more restrictive on.
>>
<--------snip---------->
>Depending on how this is done, neither method conforms to RFC822,
>which the mail system is *supposed* to be enforcing.
>
>The key is the text between any brackets (< and >), if that's not
>a valid email address (read: had an @ sign, and is in a domain
>that's valid). With that said, the following form is valid:
>
I assume emails with the following entries won't be filtered out...
Return-Path: please_do...@support.roxio.com
From: please_do...@support.roxio.com
Right?
Ron W
eqjb...@nveznvy.arg
Apply ROT13 to get real email address
Daniel Jacobson
> I assume emails with the following entries won't be filtered out...
> Return-Path: please_do...@support.roxio.com
> From: please_do...@support.roxio.com
> Right?
That is an incorrect way to SPAM block *if* support.roxio.com was
a valid domain name.
Address Munging FAQ:Spam-Blocking Your Email Address
http://members.aol.com/emailfaq/mungfaq.html
Specifically
http://members.aol.com/emailfaq/mungfaq.html#how-mung
Ron W
>In article <F84D6D51F7C7394D.279BA0F7...@lp.airnews.net>, nos...@myhouse.now says...
>
>> I assume emails with the following entries won't be filtered out...
>> Return-Path: please_do...@support.roxio.com
>> From: please_do...@support.roxio.com
>> Right?
>
> That is an incorrect way to SPAM block *if* support.roxio.com was
> a valid domain name.
>
Roxio is a division of Adaptec. And, Adaptec's support is now carried
through Roxio.com. They make you use their web page form to address support
questions and follow-ups to questions already with case numbers. They don't
respond to direct email. So, any support you get from Adaptec is coming
with this kind of Return Path: and From: line.
If this kind of message is blocked so is their support. That's why I asked
the question.
Ron W
> Address Munging FAQ:Spam-Blocking Your Email Address
> http://members.aol.com/emailfaq/mungfaq.html
>
> Specifically
> http://members.aol.com/emailfaq/mungfaq.html#how-mung
> --
> Over and Out
> Daniel Jacobson
eqjb...@nveznvy.arg
Daniel Jacobson
>>> I assume emails with the following entries won't be filtered out...
>>> Return-Path: please_do...@support.roxio.com
>>> From: please_do...@support.roxio.com
>>> Right?
>> That is an incorrect way to SPAM block *if* support.roxio.com was
>> a valid domain name.
>>
>> Address Munging FAQ:Spam-Blocking Your Email Address
>> http://members.aol.com/emailfaq/mungfaq.html
>>
>> Specifically
>> http://members.aol.com/emailfaq/mungfaq.html#how-mung
> Roxio is a division of Adaptec. And, Adaptec's support is now carried
> through Roxio.com. They make you use their web page form to address support
> questions and follow-ups to questions already with case numbers. They don't
> respond to direct email. So, any support you get from Adaptec is coming
> with this kind of Return Path: and From: line.
>
> If this kind of message is blocked so is their support. That's why I asked
> the question.
Well roxio.com is valid:
Registrant:
ADAPTEC (ROXIO-DOM)
691 S. Milpitas Blvd
MILPITAS, CA 95035
US
Domain Name: ROXIO.COM
Administrative Contact, Technical Contact, Billing Contact:
ADAPTEC (N202-OR) be...@corp.adaptec.com
ADAPTEC
691 S. Milpitas Blvd
MILPITAS, CA 95035
US
408 945 8600 fax: 123 123 1234
Record last updated on 25-Sep-2000.
Record expires on 22-Jun-2001.
Record created on 22-Jun-2000.
Database last updated on 10-Dec-2000 03:17:27 EST.
Domain servers in listed order:
NS1.DIGISLE.NET 167.216.128.34
NS2.DIGISLE.NET 167.216.192.18
But, support.roxio.com is not valid at this time regardless
of the invalid user name "please_do_not_reply" ?
NO MATCH via whois.networksolutions.com ?
So I *think* what you are asking...
Will a return address (From:) with an invalid user name as well
as an invalid domain name bounce and not get delivered?
I think the key point here is the message will not *originate*
through the IA mail server.
I think that depends on *their* mail server and not IA's
mail server. As long as the To: address is a valid address,
the message will be *delivered* to an IA customer.
If you tried to send a message *originating* through the
IA mail server with a From: address of
please_do...@support.roxio.com, the message would
bounce back to you.
Support can you verify the above?
Ron W
Nuckolls and or Bill Harris to reply to this question. This is a legitimate
question and one of concern.
As I said in my original post, Adaptec aka Roxio uses this "from" to
respond to support questions via email. IA filtering this message out would
in effect deprive me of support for one of my software packages.
Bill? James? Answers?
Ron W
eqjb...@nveznvy.arg