in my /etc/mail/access I have list of servers / domain that are
discarted.
The question I have is :
Is the e-mail still downloaded ( transferd ) first and then discarted,
or is the mail discarted on the remote server?
Has the discarted e-mail taken the bandwith or not
Many thanks for your answers.

On Thu, 16 Aug 2007, SarDameAveline wrote:

>
> in my /etc/mail/access I have list of servers / domain that are
> discarted.
> The question I have is :
> Is the e-mail still downloaded ( transferd ) first and then discarted,
> or is the mail discarted on the remote server?
> Has the discarted e-mail taken the bandwith or not
> Many thanks for your answers.


The email would normally not have been accepted, it would be after the
helo/ehlo, if you use delay_checks its -
helo (ehlo)
mail from:
rcpt to:
now ill reject you before the "data" so it might cost you a few hundred
bytes in connection info, thats all, so basically its not used any
bandwith.



--

Cheers
Res

On 16 août, 13:28, Res <r...@ausics.net> wrote:
> On Thu, 16 Aug 2007, SarDameAveline wrote:
>
> > in my /etc/mail/access I have list of servers / domain that are
> > discarted.
> > The question I have is :
> > Is the e-mail still downloaded ( transferd ) first and then discarted,
> > or is the mail discarted on the remote server?
> > Has the discarted e-mail taken the bandwith or not
> > Many thanks for your answers.
>
> The email would normally not have been accepted, it would be after the
> helo/ehlo, if you use delay_checks its -
> helo (ehlo)
> mail from:
> rcpt to:
> now ill reject you before the "data" so it might cost you a few hundred
> bytes in connection info, thats all, so basically its not used any
> bandwith.
>
> --
>
> Cheers
> Res

I might have been rejected ( discarted ) but while connected to my
server using telnet server 25.
and
mail from: me@yahoo.fr
-----------------> at this moment ( using tail -f /var/adm/syslog ) It
logs
Aug 16 15:41:34 dacp sendmail[13562]: [ID 801593 mail.notice]
l7GDdICi013562: ruleset=check_mail, arg1=ici@yahoo.fr, relay=dacp
[198.132.48.8], discard
BUT I can continue with
rcpt to:andre
250 2.1.5 andre ... Recipient ok
data
354 Enter mail, end with "." on a line by itself
jhdsfkljsdf
dhfgh
fgjhfhdj
ghdjdghjghdj
hgdjgdhjghd
..
250 2.0.0 l7GDdICh013562 Message accepted for delivery

so ? when is the communication "discarted "

SarDameAveline

On 08/16/07 08:46, SarDameAveline wrote:
> I might have been rejected ( discarted ) but while connected to my
> server using telnet server 25.
> and
> mail from: me@yahoo.fr
> -----------------> at this moment ( using tail -f /var/adm/syslog ) It
> logs
> Aug 16 15:41:34 dacp sendmail[13562]: [ID 801593 mail.notice]
> l7GDdICi013562: ruleset=check_mail, arg1=ici@yahoo.fr, relay=dacp
> [198.132.48.8], discard
> BUT I can continue with
> rcpt to:andre
> 250 2.1.5 andre ... Recipient ok
> data
> 354 Enter mail, end with "." on a line by itself
> jhdsfkljsdf
> dhfgh
> fgjhfhdj
> ghdjdghjghdj
> hgdjgdhjghd
> .
> 250 2.0.0 l7GDdICh013562 Message accepted for delivery
>
> so ? when is the communication "discarted "

This particular message has been accepted by your server and not discarded.

220 your server ESMTP
EHLO your client
250-bla
250-...
250 ...
mail from:me@yahoo.fr
250 2.1.0 <me@yahoo.fr>... Sender ok
rcpt to:<andre@domain.tld>
550 5.7.1 denied

In this (mach) scenario the server rejects the message in response to
the "RCPT TO:" SMTP command never allowing the SMTP transaction to
progress to the DATA phase which is where most of the bandwidth is used
/ wasted.



Grant. . . .

In article <1187261841.125936.104150@w3g2000hsg.googlegroups. com>
SarDameAveline <ahr@swing.be> writes:
>in my /etc/mail/access I have list of servers / domain that are
>discarted.
>The question I have is :
>Is the e-mail still downloaded ( transferd ) first and then discarted,
>or is the mail discarted on the remote server?
>Has the discarted e-mail taken the bandwith or not

Ignore the other responses. There is no provision for discarding
messages in the SMTP protocol, it's something that just shouldn't be
done, see the RFCs. Thus the only way to do it anyway is to pretend to
accept the message and then throw it away. I.e. the message will always
be transfered when you use DISCARD in the access DB.

--Per Hedeland
per@hedeland.org

On 08/16/07 13:47, Per Hedeland wrote:
> Ignore the other responses. There is no provision for discarding
> messages in the SMTP protocol, it's something that just shouldn't be
> done, see the RFCs. Thus the only way to do it anyway is to pretend
> to accept the message and then throw it away. I.e. the message will
> always be transfered when you use DISCARD in the access DB.

Ok, I'll bite.

Are you wanting to get in to a symantec discussion / disagreement over
the words "discard" and "reject" or are you thinking something else? Or
have you not had enough of your morning beverage of choice yet?

It is completely possible for a server to return a "Permanent Failure
Code (5xx series)" to any command during the SMTP Transaction to
"reject" the message entirely. This rejection usually induces the
sending host to consider the message transfer a permanent failure and
not try to deliver it again but to usually deliver a notification of
such failure to the original envelope sender of the message.

Or have I just completely missed something here? If so please enlighten
me. Thank you.



Grant. . . . .

Grant Taylor <gtaylor@riverviewtech.net> wrote:

> On 08/16/07 13:47, Per Hedeland wrote:
> > Ignore the other responses. There is no provision for discarding
> > messages in the SMTP protocol, it's something that just shouldn't be
> > done, see the RFCs. Thus the only way to do it anyway is to pretend
> > to accept the message and then throw it away. I.e. the message will
> > always be transfered when you use DISCARD in the access DB.
>
> Ok, I'll bite.
>
> Are you wanting to get in to a symantec discussion / disagreement over
> the words "discard" and "reject" or are you thinking something else? Or
> have you not had enough of your morning beverage of choice yet?
>
> It is completely possible for a server to return a "Permanent Failure
> Code (5xx series)" to any command during the SMTP Transaction to
> "reject" the message entirely. This rejection usually induces the
> sending host to consider the message transfer a permanent failure and
> not try to deliver it again but to usually deliver a notification of
> such failure to the original envelope sender of the message.
>
> Or have I just completely missed something here? If so please enlighten
> me. Thank you.
>

The OP especialy used the word "discarted" and not rejected. As he is
using the "DISCARD" keyword in access db and not one of the forms of
REJECT.

The exemple of syslog he gave is exactly what I get when I test how a
"From:x@x DISCARD" entry works.

Per Hedeland answer is correct.

The OP most probably would be better with REJECTs though. Especialy if
he is worrying about saving bandwidth.

In article
<mailman.39.1187298746.11203.comp.mail.sendmail@ma illists.riverviewtech.net>
Grant Taylor <gtaylor@riverviewtech.net> writes:
>On 08/16/07 13:47, Per Hedeland wrote:
>> Ignore the other responses. There is no provision for discarding
>> messages in the SMTP protocol, it's something that just shouldn't be
>> done, see the RFCs. Thus the only way to do it anyway is to pretend
>> to accept the message and then throw it away. I.e. the message will
>> always be transfered when you use DISCARD in the access DB.

>Or have I just completely missed something here? If so please enlighten
>me. Thank you.

Apparently that the question was about the effects of using DISCARD in
sedmail's access db.

--Per Hedeland
per@hedeland.org