from=<>
Simon White
> I seem to be getting emails from
>
> from=<>
>
> Can someone please explain what this means and how I can stop it?
<> is RFC compliant. These are bounces
However, some spammers have started using that address (the "null"
address) as their sender address.
You must not block this kind of address, you're going to have to find
another way to stop them (blocking the guilty IP, using RBLs, etc)
I am saddened to see this sullying of the <> address by spammers.
--
[Simon White. vim/mutt. si...@mtds.com. Folding@home no log script yet...]
If you don't like what is going on in Palestine, or are curious, look:
http://www.inminds.com/boycott-israel.html
I am not anti-jewish. I am against the Israeli régime headed by Sharon.
Noel Jones
>I seem to be getting emails from
>
>from=<>
>
>Can someone please explain what this means and how I can stop it?
The null or empty sender address <> is used for bounces.
Don't block it.
RFC's require that you accept bounces; ie. mail with the null sender
address. If you decide to reject such mail, many sites will refuse to
accept mail from you, and your users may not be notified if mail they send
is undeliverable.
It's OK to reject this mail for other reasons, such as the client being
listed on an RBL or it being directed to an unknown user on your
system. But don't block based on the null sender address.
check out
http://www.rfc-ignorant.org/policy-dsn.php
for more info.
Lately, I've noticed more and more sites blocking null sender
addresses. Seems they often are running IMail. I wonder if the IMail
docs say something that leads people to belive it's OK to reject bounces...
--
Noel Jones
-
To unsubscribe from the postfix-users list, click the link below:
<mailto:majo...@postfix.org?body=unsubscribe%20postfix-users>
Scott Antonivich
from=<>
Can someone please explain what this means and how I can stop it?
Thanks
Scott
Ralf Hildebrandt
> However, some spammers have started using that address (the "null"
> address) as their sender address.
Postfix to the rescue:
reject_multi_recipient_bounce
--
Ralf Hildebrandt Ralf.Hil...@charite.de
my current spamtrap partmap...@charite.de
http://www.arschkrebs.de/postfix/ Tel. +49 (0)30-450 570-155
Why you can't find your system administrators:
(S)he's in a meeting with the boss to discuss poor user response times. -- Ade Rixon a...@rheidol.elsevier.co.uk
Cybertime Hostmaster
> addresses. Seems they often are running IMail. I wonder if the IMail
> docs say something that leads people to belive it's OK to reject
bounces...
Actually, they warn that by turning this check on you are becoming
non-standards complaint. But they sill leave it as an option due to massive
customer demand.
Personally, I think that if they are stupid enough to make it as an option,
and know the consequences, they should have at least put more warning in
than they have.
--Eric
Simon White
Your choice not to be RFC compliant could get your mail refused by some
people.
--
[Simon White. vim/mutt. si...@mtds.com. Folding@home no log script yet...]
How to ask Questions the Smart Way, by Eric S. Raymond. Including before
you ask, when you ask, how to interpret answers, and on not reacting like
a loser -- http://www.tuxedo.org/~esr/faqs/smart-questions.html
Noel Jones
> > Personally, I think that if they are stupid enough to make it as an option,
> > and know the consequences, they should have at least put more warning in
> > than they have.
>
>Your choice not to be RFC compliant could get your mail refused by some
>people.
When I contact these misguided sysadmins, I try to remind them that their
users will not receive bounce notices, and so can never be sure their mail
has been delivered. This is a direct value to *their* users.
not that I've had much luck...
Unfortunately, a couple of them are domains I am required to accept mail from.
Maybe I should redirect undeliverable bounces to sup...@ipswitch.com
Vivek Khera
RH> * Simon White <si...@mtds.com>:
>> However, some spammers have started using that address (the "null"
>> address) as their sender address.
RH> Postfix to the rescue:
RH> reject_multi_recipient_bounce
Which version?
[onceler]% postconf |grep multi
[onceler]% postconf -d mail_version
mail_version = 2.0.2
Cybertime Hostmaster
> > > addresses. Seems they often are running IMail. I wonder if the
> > > IMail docs say something that leads people to belive it's OK to
> > > reject bounces...
> >
> > Actually, they warn that by turning this check on you are becoming
> > non-standards complaint. But they sill leave it as an option due to
massive
> > customer demand.
> >
option,
> > and know the consequences, they should have at least put more warning in
> > than they have.
>
> Your choice not to be RFC compliant could get your mail refused by some
> people.
I said they, not me. They as in IPSwitch.
The configuration and administration software for IMail has warnings on some
commands. I just think they need more if IPSwitch is going to continue
being stupid enough to let their software be non-standards compliant.
--Eric
Stephen Satchell
>> > Personally, I think that if they are stupid enough to make it as an
>> option,
>> > and know the consequences, they should have at least put more warning in
>> > than they have.
>>
>>Your choice not to be RFC compliant could get your mail refused by some
>>people.
>
>users will not receive bounce notices, and so can never be sure their mail
>has been delivered. This is a direct value to *their* users.
>
>not that I've had much luck...
>
>Unfortunately, a couple of them are domains I am required to accept mail from.
That, incidentally, is one reason I run my own MTA -- the log entries let
me notify users that their mail DID make it to some MX successfully,
although it doesn't let them know about downstream problems (such as an MX
accepting mail for an address that the downstream MTA says is
not-a-user). My ISP's sysadmin is one who blocks "<>" addresses because of
the number of spammers who STILL use that as a source address. Fewer and
fewer every day, but only because those misguided sysadmins continue to
block mail from the null user.
What up-to-date MTA still uses the <> address for bounce messages?
Tomasz Papszun
>
> That, incidentally, is one reason I run my own MTA -- the log entries let
> me notify users that their mail DID make it to some MX successfully,
> although it doesn't let them know about downstream problems (such as an MX
> accepting mail for an address that the downstream MTA says is
> not-a-user). My ISP's sysadmin is one who blocks "<>" addresses because of
> the number of spammers who STILL use that as a source address. Fewer and
> fewer every day, but only because those misguided sysadmins continue to
> block mail from the null user.
>
> What up-to-date MTA still uses the <> address for bounce messages?
>
Probably every one :-) .
--
Tomasz Papszun SysAdm @ TP S.A. Lodz, Poland | And it's only
to...@lodz.tpsa.pl http://www.lodz.tpsa.pl/ | ones and zeros.
Noel Jones
>What up-to-date MTA still uses the <> address for bounce messages?
Um, all that are RFC compliant?
bounces must be sent with the null sender address to prevent mail loops.
Wietse Venema
> What up-to-date MTA still uses the <> address for bounce messages?
Any MTA that aims to be standards compliant.
Replacing <> by <postm...@any.domain.tld> does not make SPAM go away.
Wietse
Ralf Hildebrandt
> What up-to-date MTA still uses the <> address for bounce messages?
All, because it's the only way to prevent loops.
--
Ralf Hildebrandt Ralf.Hil...@charite.de
my current spamtrap partmap...@charite.de
http://www.arschkrebs.de/postfix/ Tel. +49 (0)30-450 570-155
NT vs UNIX, why UNIX: It doesn't matter how big or hot your
thing is at the moment if it doesn't stay up or perform.
Ralf Hildebrandt
> RH> reject_multi_recipient_bounce
>
> Which version?
>
> [onceler]% postconf |grep multi
It's a restriction for e.g. smtpd_recipient_restrictions
> [onceler]% postconf -d mail_version
> mail_version = 2.0.2
20021130
Feature: new reject_multi_recipient_bounce restriction, to
reject "MAIL FROM: <>" with multiple recipients. File:
smtpd/smtpd_check.c.
--
Ralf Hildebrandt Ralf.Hil...@charite.de
my current spamtrap partmap...@charite.de
http://www.arschkrebs.de/postfix/ Tel. +49 (0)30-450 570-155
UNIX is an operating system, OS/2 is half an operating system, Windows
is a shell, and DOS is a boot partition virus." -- Peter H. Coffin
Brian D. Cook
turned on.. But what is/was it?
I couldn't find it in the uce controls page.
Brian
-----Original Message-----
From: owner-pos...@postfix.org
[mailto:owner-pos...@postfix.org] On Behalf Of Ralf Hildebrandt
Sent: Tuesday, January 28, 2003 3:26 PM
To: postfi...@postfix.org
Subject: Re: from=<>
* Stephen Satchell <li...@fluent2.pyramid.net>:
> What up-to-date MTA still uses the <> address for bounce messages?
All, because it's the only way to prevent loops.
--
Ralf Hildebrandt
Ralf.Hil...@charite.de
my current spamtrap
partmap...@charite.de
http://www.arschkrebs.de/postfix/ Tel. +49 (0)30-450
570-155
Ralf Hildebrandt
> Does postfix have an option to block that? I know it shouldn't be
> turned on.. But what is/was it?
>
> I couldn't find it in the uce controls page.
The solution is left as an exercise to the reader :)
Hint: "null"
--
Ralf Hildebrandt Ralf.Hil...@charite.de
my current spamtrap partmap...@charite.de
http://www.arschkrebs.de/postfix/ Tel. +49 (0)30-450 570-155
Why you can't find your system administrators:
Is closeted with boss trying to explain why (s)he uploaded a user to seven.rings.of.hell.com
Vivek Khera
>> [onceler]% postconf -d mail_version
>> mail_version = 2.0.2
RH> 20021130
RH> Feature: new reject_multi_recipient_bounce restriction, to
RH> reject "MAIL FROM: <>" with multiple recipients. File:
RH> smtpd/smtpd_check.c.
Must be a snapshot, since the 2.0.2 HISTORY doesn't have this entry,
and grepping for "reject_multi" in the sources and docs finds nothing.
brian moore
> When I contact these misguided sysadmins, I try to remind them that their
> users will not receive bounce notices, and so can never be sure their mail
> has been delivered. This is a direct value to *their* users.
Tried advising their users? That's what I used to do a LOT. I'd give
them a little test: send mail to "no-one-here-...@aol.com" and
tell them to wait for the bounce. And keep waiting. When they see that
a simple typo will make their mail disappear with no notice, the
"solution" is to follow up every email with a phone call. Or get a new
provider that doesn't lose their mail.
--
| If there were no windows that we sit inside
brian moore <b...@rom.org> | If there were no ugly feelings, would we be alive?
| -- the residents
Rahul Dhesi
> Postfix to the rescue:
>
> reject_multi_recipient_bounce
Not documented in Postfix 2.0.2.
Rahul
Michael Hall
ukiah: $ postconf mail_version
mail_version = 2.0.3-20030124
from sample-smtpd.cf
# The smtpd_recipient_restrictions parameter specifies restrictions on
# recipient addresses that SMTP clients can send in RCPT TO commands.
#
...
#
# The following restrictions are available (* is part of default setting):
#
# *permit_mynetworks: permit if the client address matches $mynetworks.
# reject_unknown_sender_domain: reject sender domain without A or MX record.
# reject_unverified_sender: reject undeliverable sender address.
# reject_unverified_recipient: reject undeliverable recipient address.
# reject_multi_recipient_bounce: reject mail from <> with multiple recipients.
...
--
Humpty Dumpty was pushed!
Mike Hall,
Unix Admin - Rock Island Communications <mi...@rockisland.com>
System Admin - riverside.org <mh...@riverside.org>
Rahul Dhesi
> On Tue, Jan 28, 2003 at 03:10:34PM -0800, Rahul Dhesi wrote:
>
> > On Tue, Jan 28, 2003 at 07:16:05PM +0100, Ralf Hildebrandt wrote:
> >
> > > Postfix to the rescue:
> > >
> > > reject_multi_recipient_bounce
> >
> > Not documented in Postfix 2.0.2.
>
> ukiah: $ postconf mail_version
> mail_version = 2.0.3-20030124
Thank-you. We count on helpful people like you to add the essential
context that is missing from Ralf's cryptic half-answers.
Rahul
Simon White
> On Tue, Jan 28, 2003 at 01:13:43PM -0600, Noel Jones wrote:
> > When I contact these misguided sysadmins, I try to remind them that their
> > users will not receive bounce notices, and so can never be sure their mail
> > has been delivered. This is a direct value to *their* users.
>
> Tried advising their users? That's what I used to do a LOT. I'd give
> them a little test: send mail to "no-one-here-...@aol.com" and
> tell them to wait for the bounce. And keep waiting. When they see that
> a simple typo will make their mail disappear with no notice, the
> "solution" is to follow up every email with a phone call. Or get a new
> provider that doesn't lose their mail.
If users ask me to do something just to make their lives easier, just
because they get a couple of spams from a null sender, then I might have
the time to explain to them how better to filter spam and save bandwidth
(use IMAP instead, or subscribe to our SpamAssassin/Virusscan service)
but I would *never* block null senders just to reduce spam by a marginal
percentage. If all spam came from null senders, then there really would
be problems.
But really, blocking null sender is almost equivalent to nailing up your
physical mailbox/letterbox/boîte à lettres so that you don't receive
advertising in the mail. Just plain crazy.
Email should *never* get lost, but it's amazing how many people (perhaps
due to those fools who block the null sender address or do other crazy
anti-RFC stuff) think there is a "black hole" somewhere on the Internet
that loses mail. It sometimes takes me as long as ten minutes on the
phone to explain to my customers why they could never lose mail from OUR
server, so that it has to be someone else's.
Cheers,
--
[Simon White. vim/mutt. si...@mtds.com. Folding@home no log script yet...]
Sometimes we sit and read other people's interpretations of our lyrics and
think, 'Hey, that's pretty good.' If we liked it, we would keep our mouths
shut and just accept the credit as if it was what we meant all along.
-- John Lennon.
gbsales
message to a know mail server with a made up user. I recieved a
bounce back telling me this was a bad address. I am using iMail 7.x.
gbs
b...@rom.org (brian moore) wrote in message news:<b16uaa$14jv$1...@FreeBSD.csie.NCTU.edu.tw>...