* Bob Beck [EMAIL PROTECTED] [2007-05-24 08:22]:
rfc 2821 specifically forbids this behaviour.
quote
The DATA command can fail at only two points in the protocol exchange:
- If there was no MAIL, or no RCPT, command, or all such commands
were rejected, the server MAY
On May 24, 2007, at 8:35 AM, Henning Brauer wrote:
* Bob Beck [EMAIL PROTECTED] [2007-05-24 08:22]:
rfc 2821 specifically forbids this behaviour.
quote
The DATA command can fail at only two points in the protocol
exchange:
- If there was no MAIL, or no RCPT, command, or all such
yes, but not in response to the DATA command (what I was talking about)
but after.
no, you're wrong. right from rfc 2821:
8
DATA
I: 354 - data - S: 250
E: 552, 554, 451, 452
E: 451, 554, 503
8
explicitly - if I decide something is wrong
* Bob Beck [EMAIL PROTECTED] [2007-05-24 17:13]:
yes, but not in response to the DATA command (what I was talking about)
but after.
no, you're wrong. right from rfc 2821:
8
DATA
I: 354 - data - S: 250
E: 552, 554, 451, 452
E: 451, 554,
On 5/24/07, Henning Brauer [EMAIL PROTECTED] wrote:
...
the table totally contradicts the text... kind of funny :)
Perhaps that's why the current internet-draft for the revision of RFC
2821 has this in the table:
DATA
I: 354 - data - S: 250
E: 552,
* Renaud Allard [EMAIL PROTECTED] [2007-05-22 14:15]:
Indeed, but it could cause you to get blacklisted by some automated
checkers
no, that is bullshit.
those checkers do not exist any more (or they went irrelevant).
it has been proven many many many moons ago that this kind of test is
* Bob Beck [EMAIL PROTECTED] [2007-05-22 23:45]:
just deduced from trial and error. Also greylisting should happen at
RCPT TO, and probably not at DATA as there are some widely used MTAs
that are buggy and choke when a 4xx error is sent in the DATA phase.
I've been running this at
Henning Brauer wrote:
err, wait, are you giving a 4xx in reply to DATA?
that is invalid.
The response to the DATA command is 354 as it should. But at the end of
the DATA phase, a 451 is returned.
--
01010010011001010110111001110111010101100100
On 5/23/07, Henning Brauer [EMAIL PROTECTED] wrote:
...
err, wait, are you giving a 4xx in reply to DATA?
that is invalid.
At least for 451 and 421 replies, it sure seems legal to me. To quote RFC 2821:
4.3.2 Command-Reply Sequences
...
In addition to the codes listed below, any SMTP
* Henning Brauer [EMAIL PROTECTED] [2007-05-23 11:48]:
* Bob Beck [EMAIL PROTECTED] [2007-05-22 23:45]:
just deduced from trial and error. Also greylisting should happen at
RCPT TO, and probably not at DATA as there are some widely used MTAs
that are buggy and choke when a 4xx error is
* Renaud Allard [EMAIL PROTECTED] [2007-05-23 12:10]:
Henning Brauer wrote:
rfc 2821 specifically forbids this behaviour.
Not really.
quote
- If the verb is initially accepted and the 354 reply issued, the
DATA command should fail only if the mail transaction was
Renaud Allard [EMAIL PROTECTED] writes:
I just used dnsstuff to test one of my domain names and it showed me
(the first time only) that my server is an openrelay, which is obviously
not true. This is due to the default behaviour of spamd of accepting
everything, even when a
Peter N. M. Hansteen wrote:
Renaud Allard [EMAIL PROTECTED] writes:
I just used dnsstuff to test one of my domain names and it showed me
(the first time only) that my server is an openrelay, which is obviously
not true. This is due to the default behaviour of spamd of accepting
everything,
Renaud Allard [EMAIL PROTECTED] writes:
Indeed, but it could cause you to get blacklisted by some automated
checkers, which is clearly something you don't want. I know this kind of
checker is not accurate, but some local checkers will do it that way and
you will end up with the problems.
Peter N. M. Hansteen wrote:
Renaud Allard [EMAIL PROTECTED] writes:
Indeed, but it could cause you to get blacklisted by some automated
checkers, which is clearly something you don't want. I know this kind of
checker is not accurate, but some local checkers will do it that way and
you will
On 2007/05/22 14:49, Renaud Allard wrote:
I speak mostly of SMTP-time checkers. Imagine you are sending a mail to
someone and while you are doing the SMTP transaction, the remote host
also connects to your server to see if it may be an openrelay.
They are broken then... Workaround: use
Stuart Henderson wrote:
They are broken then... Workaround: use different mailer instances on
different IP addresses for incoming and outgoing mail (this is often a
good idea anyway).
This workaround only works if the checker connects to your MX, not to
the host sending the mail. I know they
On 2007/05/22 15:50, Renaud Allard wrote:
Stuart Henderson wrote:
They are broken then... Workaround: use different mailer instances on
different IP addresses for incoming and outgoing mail (this is often a
good idea anyway).
This workaround only works if the checker connects to your
Stuart Henderson wrote:
On 2007/05/22 15:50, Renaud Allard wrote:
Stuart Henderson wrote:
You wouldn't need spamd on the address of a send-only instance..
(if mail's only submitted on 587/465 or from known address ranges, it
could just RST port 25 to the rest of the world).
Good point :)
Renaud Allard wrote:
I think a better solution would be for *more* people to use greylisting
implementations which do this, so that more MSexchange users will either
bother Microsoft to fix their bug, or script 'net stop smtpsvc;net start
smtpsvc' to run a few times a day so they can send
On 2007/05/22 17:12, Renaud Allard wrote:
I have only seen this when the 4xx error is sent at DATA time, not when
sent at RCPT TO.
How about: --i-dont-want-to-receive-mail-from-people-using-exchange-2003
and --i-dont-want-to-receive-mail-from-people-using-callout-verification
Those are
Stuart Henderson wrote:
On 2007/05/22 17:12, Renaud Allard wrote:
I have only seen this when the 4xx error is sent at DATA time, not when
sent at RCPT TO.
How about: --i-dont-want-to-receive-mail-from-people-using-exchange-2003
and
I just used dnsstuff to test one of my domain names and it showed me
(the first time only) that my server is an openrelay, which is obviously
not true. This is due to the default behaviour of spamd of accepting
everything, even when a spamd.alloweddomains file is present. I think
this could
Bob Beck wrote:
Any automated test I've ever set up for open relay, (and I run
them) as well as any sane ones I ever see test for open relay by
actually relaying a message not looking at the smtp dialoge.
You're making much ado over nothing and spreading FUD -
the tester you
Jacob Yocom-Piatt wrote:
Renaud Allard wrote:
I think a better solution would be for *more* people to use greylisting
implementations which do this, so that more MSexchange users will
either
bother Microsoft to fix their bug, or script 'net stop smtpsvc;net
start
smtpsvc' to run a few
Bob Beck wrote:
Any automated test I've ever set up for open relay, (and I run
them) as well as any sane ones I ever see test for open relay by
actually relaying a message not looking at the smtp dialoge.
You're making much ado over nothing and spreading FUD -
the tester you
Darth Lists wrote:
Unfortunately, this little MS-behaviour is very likely to be the last
straw that gets our greylisting turned off here.
Despite my logs that prove that greylisting has removed over 95% of
incoming spam before spamassassin has to deal with it, the fact that
some legitimate
just deduced from trial and error. Also greylisting should happen at
RCPT TO, and probably not at DATA as there are some widely used MTAs
that are buggy and choke when a 4xx error is sent in the DATA phase.
I've been running this at DATA for months, and not seen any
issues with it.
Bob Beck wrote:
just deduced from trial and error. Also greylisting should happen at
RCPT TO, and probably not at DATA as there are some widely used MTAs
that are buggy and choke when a 4xx error is sent in the DATA phase.
I've been running this at DATA for months, and not seen any
I manage about 30 mail servers, all using greylisting for years (not
OpenBSD spamd, but a version running in the MTA). But as I greylist at
RCPT TO, I only noticed the problem it when clamav did go down and the
server was producing a 4xx error at DATA when it should have scanned the
mail.
Bob Beck wrote:
I have definately seen issues here with other implemntations,
because the 4XX code given, the XX's matter... Have you seen
this with OpenBSD spamd? (As opposed to something else..)
I have seen this with 451 errors, not on spamd but with the exact same
error code as
31 matches
Mail list logo
