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: 5
* 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
>
> 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 wro
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.
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
command
* Bob Beck <[EMAIL PROTECTED]> [2007-05-24 08:22]:
> > rfc 2821 specifically forbids this behaviour.
> >
> >
> > 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 serve
> rfc 2821 specifically forbids this behaviour.
>
>
> 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 return a "command out of sequence"
> (503) or "no val
Henning Brauer wrote:
>
> rfc 2821 specifically forbids this behaviour.
>
Not really.
- If the verb is initially accepted and the 354 reply issued, the
DATA command should fail only if the mail transaction was
incomplete ~snip~ or if the server determines that the
messag
* Renaud Allard <[EMAIL PROTECTED]> [2007-05-23 12:10]:
>
>
> Henning Brauer wrote:
>
> >
> > rfc 2821 specifically forbids this behaviour.
> >
>
> Not really.
>
>
>- If the verb is initially accepted and the 354 reply issued, the
> DATA command should fail only if the mail transaction
* 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 4
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 comm
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
01010110110001101100011101110
* 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
* 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
us
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 a
> 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:
>> 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
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 se
> 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.
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 legiti
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 test
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 times
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 teste
> 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 cou
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-dont-want-to-receive-mail-from-people-using-
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
>
> Th
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 mail
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 poin
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 connect
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 t
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 diffe
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
>
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:
>
>> 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
>> e
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 spamd.allowed
Hello,
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
35 matches
Mail list logo
