Nabble - cr.yp.to - qmail

RE: reverse dns check and multiples ptr records

2009-12-04T12:14:01Z

> -----Message d'origine-----
> De : Rejaine Monteiro [mailto:rejaine@...]
> Envoyé : 4 décembre 2009 14:28
> À : Qmail mailing list
> Objet : Re: reverse dns check and multiples ptr records
>
>
> Maxime Ducharme escreveu:
> > Possible workaround, disable RBL verification on this IP since you know
> it.
> >
>
> yes, I do this.. but, how can I configure rblsmtp to prevent or ignore
> cases like that in the future?
>
> the e-mail come from host "ms.casaevideo.com.br " and this is OK:
>
> # host ms.casaevideo.com.br
> ms.casaevideo.com.br has address 200.214.6.6
>
> but they have others two domains, which are the point of failure:
>
> this domain resolve to another address:
>
> # host ms.ventiladorspirit.com.
> ms.ventiladorspirit.com has address 208.73.210.27
>
> and this , to nothing...
>
> #host ms.ventiladorspirit.com.br.
> Host ms.ventiladorspirit.com.br. not found: 3(NXDOMAIN)

Hmmm this is not good since an invalid PTR was set by the foreign sysadmin.
I usually see multiple PTRs on mass hosting servers which have automated DNS
configuration. I dont think having multiple PTR RRs are a good thing. I am
sure having invalid PTR is a problem tough, this problem is similar of NOT
having any PTR set.

I suggest that you contact its sysadmin and ask him to remove invalid PTRs,
just like you would tell a foreign sysadmin that he forgot to configure a
PTR that he is unable to send mail to your mail server.

>
> and it only interests me this domain: casaevideo.com.br.
>

Re: reverse dns check and multiples ptr records

2009-12-04T11:28:20Z

Maxime Ducharme escreveu:
> Possible workaround, disable RBL verification on this IP since you know it.
>

yes, I do this.. but, how can I configure rblsmtp to prevent or ignore cases like that in the future?

the e-mail come from host "ms.casaevideo.com.br " and this is OK:

# host ms.casaevideo.com.br
ms.casaevideo.com.br has address 200.214.6.6

but they have others two domains, which are the point of failure:

this domain resolve to another address:

# host ms.ventiladorspirit.com.
ms.ventiladorspirit.com has address 208.73.210.27

and this , to nothing...

#host ms.ventiladorspirit.com.br.
Host ms.ventiladorspirit.com.br. not found: 3(NXDOMAIN)

and it only interests me this domain: casaevideo.com.br.

RE: reverse dns check and multiples ptr records

2009-12-04T11:07:13Z

> -----Message d'origine-----
> De : Rejaine Monteiro [mailto:rejaine@...]
> Envoyé : 4 décembre 2009 12:00
> À : qmail@...
> Objet : reverse dns check and multiples ptr records
>
>
> hi,

Hi

>
> i'm using rlbsmtd to block bad reverse dns..
> but, i'm having problems with a particular domain named
> 'casaevideo.com.br' ..
>
> sometimes, mail from this mta domain is accepted and sometimes is
> rejectecd with ' rblsmtpd: 200.214.6.6 'Bad reverse DNS'
>
> i suspect the problem is multiple PTR entries on DNS:

I also see the same configuration. I do not know how rblsmtpd will react
about this, I am also curious to know about it. I also believe the reverse
DNS checks are done at tcpserver level, are you using a = sign in tcprules
file ?

See
http://cr.yp.to/ucspi-tcp/tcprules.html
4. =$TCPREMOTEHOST, if $TCPREMOTEHOST is set;

The = sign will match if tcpserver found a reverse DNS and filled env var
TCPREMOTEHOST

>
> $ host 200.214.6.6
>
> 6.0-63.6.214.200.in-addr.arpa domain name pointer ms.casaevideo.com.
> 6.0-63.6.214.200.in-addr.arpa domain name pointer ms.casaevideo.com.br.
> 6.0-63.6.214.200.in-addr.arpa domain name pointer ms.spiritstyle.com.
> 6.0-63.6.214.200.in-addr.arpa domain name pointer
> ms.cevlicenciamento.com.br.
> 6.0-63.6.214.200.in-addr.arpa domain name pointer ms.ventiladorspirit.com.
> 6.0-63.6.214.200.in-addr.arpa domain name pointer
> ms.ventiladorspirit.com.br.
> 6.0-63.6.214.200.in-addr.arpa domain name pointer ms.casavideo.com.br.
>
> //How can I resolve this problem? I appreciate any tip !

Possible workaround, disable RBL verification on this IP since you know it.

You may use tcprule to achieve this like indicated in
http://cr.yp.to/ucspi-tcp/rblsmtpd.html
and
http://cr.yp.to/ucspi-tcp/tcprules.html

It would look like this

- edit /etc/tcp.smtp

You need to add a line beginning with the IP 200.214.6.6 without an = sign,
and set an empty RBLSMTPD env var, something like :
200.214.6.6:allow,RBLSMTPD=""

You need to adjust to you current configuration, other options may have to
be set.

Have a nice day

Maxime

reverse dns check and multiples ptr records

2009-12-04T09:00:02Z

hi,

i'm using rlbsmtd to block bad reverse dns..
but, i'm having problems with a particular domain named
'casaevideo.com.br' ..

sometimes, mail from this mta domain is accepted and sometimes is
rejectecd with ' rblsmtpd: 200.214.6.6 'Bad reverse DNS'

i suspect the problem is multiple PTR entries on DNS:

$ host 200.214.6.6

6.0-63.6.214.200.in-addr.arpa domain name pointer ms.casaevideo.com.
6.0-63.6.214.200.in-addr.arpa domain name pointer ms.casaevideo.com.br.
6.0-63.6.214.200.in-addr.arpa domain name pointer ms.spiritstyle.com.
6.0-63.6.214.200.in-addr.arpa domain name pointer
ms.cevlicenciamento.com.br.
6.0-63.6.214.200.in-addr.arpa domain name pointer ms.ventiladorspirit.com.
6.0-63.6.214.200.in-addr.arpa domain name pointer
ms.ventiladorspirit.com.br.
6.0-63.6.214.200.in-addr.arpa domain name pointer ms.casavideo.com.br.

//How can I resolve this problem? I appreciate any tip !

Re: Dumb MX Record Question

2009-12-02T14:32:32Z

It doesn't really matter to me what you have or have not done - this is not the forum to discuss your life (true or not) nor social statistics. That said, you seemed to miss the intention of my email, so let me try being more clear.

If you're unwilling to read to find the answer, then you should at least try respecting the people on the list when asking a question. They're doing it for free and don't deserve to be insulted just because someone once gave you an answer that required you to do too much work. I've been lurking on this list for a long time, and everyone else seems to be able to be cordial, so it should not be impossible for you.

I've given my two cents, so out of respect for the people on this list, I'm going to stop responding to this thread.

On 12/2/2009 2:21 PM, Datesfat Chicks wrote:

On Wed, Dec 2, 2009 at 11:36 AM, Jonathan Hilgeman <jon@...> wrote:

Wow. Usually I just lurk on the list, but wow. So if I understand your priorities in order of most preferred to least:

#1. Beating yourself on the head with a hammer.
#2. Asking a question on the qmail list and lying about knowing an RFC.
#3. Looking up an RFC that you probably already know and reading a portion of it.

I mean, really. I know RFCs aren't exactly at the reading level of Harry Potter, but if you KNOW that the answer lies in an RFC, -AND- you know which RFC it is... I mean, that is just another special level of laziness to have all that information at your fingertips and yet you have to ask people to read it to you. And it's one thing to at least be polite about it, but to insult the people on the list while asking your question? That's enough to get me out of my lurking status.

As someone who hires and fires people and runs with the crowd that does the same, I can honestly say that you will not get far in this world with that type of attitude.

I really appreciate your insight into this matter and into my potential to "get far in this world".

According to you, I should never have:

a)Earned two college degrees.

b)Earned more than $100K a year.

c)Stayed gainfully employed for decades at a time.

d)Etc., etc., etc.

I can only assume that I'm a statistical outlier. A loser like me should never have accomplished anything. I guess it is just a statistical fluke.

One day my loser nature will catch up with me, I guess.

Datesfat

Re: Dumb MX Record Question

2009-12-02T13:48:50Z

Actually, I guess I am not alone on the list in not caring one way or
another what Jonathan thinks of Datefat, nor what Datefat thinks about
whatever it is Jonathan thinks of Datefat. But allow me one general
observation, aimed at no one in particular:

Very smart people can some times say and do very stupid things.
In fact it is not even uncommon. There are entire books written about
the phenomonen.

Please note that in saying so, I am not implying that anybody here is
very smart, or has said anything very stupid. But I wouldn't rule out
either possibility.

And while I have the floor, let me point out the existence of a
wonderful file called rfc-index.txt that contains a list of all the
RFCs and their titles. Try googling "rfc index" (without the quotes).

Thank you for your attention.

- Harald

Re: Dumb MX Record Question

2009-12-02T11:21:20Z

On Wed, Dec 2, 2009 at 11:36 AM, Jonathan Hilgeman <jon@...> wrote:

Wow. Usually I just lurk on the list, but wow. So if I understand your priorities in order of most preferred to least:

#1. Beating yourself on the head with a hammer.
#2. Asking a question on the qmail list and lying about knowing an RFC.
#3. Looking up an RFC that you probably already know and reading a portion of it.

I mean, really. I know RFCs aren't exactly at the reading level of Harry Potter, but if you KNOW that the answer lies in an RFC, -AND- you know which RFC it is... I mean, that is just another special level of laziness to have all that information at your fingertips and yet you have to ask people to read it to you. And it's one thing to at least be polite about it, but to insult the people on the list while asking your question? That's enough to get me out of my lurking status.

As someone who hires and fires people and runs with the crowd that does the same, I can honestly say that you will not get far in this world with that type of attitude.

I really appreciate your insight into this matter and into my potential to "get far in this world".

According to you, I should never have:

a)Earned two college degrees.

b)Earned more than $100K a year.

c)Stayed gainfully employed for decades at a time.

d)Etc., etc., etc.

I can only assume that I'm a statistical outlier. A loser like me should never have accomplished anything. I guess it is just a statistical fluke.

One day my loser nature will catch up with me, I guess.

Datesfat

Re: Dumb MX Record Question

2009-12-02T08:39:07Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wednesday, December 2 at 10:51 AM, quoth Datesfat Chicks:
> On Wed, Dec 2, 2009 at 10:50 AM, Datesfat Chicks
> <datesfat.chicks@...>wrote:
>
>> On Wed, Dec 2, 2009 at 10:22 AM, Shepherd Nhongo <shepherdzw@...>wrote:

I don't know what's up with Shepherd Nhongo, whoever that is, but (A)
he's not a regular contributor to this list, (B) he replied to you
off-list, and (C) he owes everyone on the list $100.

According to the list archives, in 2009 Shepherd Nhongo has sent 4
messages to the list, one of which was an advertisement for
squirrelmail themes (blatantly violating the mailing list policy that
everyone must agree to for every single post, and thereby owing
everyone on the list $100), another of which was rather rudely telling
me to read Life With Qmail to learn how qmail works. As I'm a longtime
contributor to the list and having published a book on qmail, I think
I can say with confidence: feel free to send Mr. Nhongo's email to
/dev/null.

And should Mr. Nhongo object, I refer him to
http://marc.info/?l=qmail&m=123374301214244&w=2 and demand my $100
dollars for his abuse of this list. As soon as he pays up, I will
withdraw my recommendation.

>> Sorry, dude, I'm a veteran of the qmail list. Whenever I'm feeling
>> self-abusive and beating myself on the head with a hammer just
>> isn't making the grade, I subscribe to the list again.

I'm sorry you feel that way. I don't know when the last time was that
you subscribed to this list, but I've been on it since at least 2003,
and it hasn't been anywhere near as hostile as you describe for a long
time. If it gets abusive, it's usually when people send email asking
questions that amount to "what kind of a moron would use qmail in this
day and age?". But when you sign on to a list designed to support
product X and heap scorn upon product X, you gotta be prepared to deal
with people defending product X.

~Kyle
- --
Our lives begin to end the day we become silent about things that
matter.
-- Martin Luther King Jr.
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJLFpgqAAoJECuveozR/AWeY6gQAKZpLDOY1xgegifh43XZPwLn
mEDbAVaONTv52tTUISc7vtmGP4qDAbU+8xadoDlHAChjM6yCKe6wUkp/yRgMaMiU
JXFr2a+jRKgQUhLmu0qJnR562fuZCYtr8Hf/FwA32E23L8auH8L2OnuEoXLwGwKm
57uuL3n7hX3F3rhDlvD8SJ9LNXw3VUPuqchCYPR3Kk8Pd/WnXsdk/QF8vod3Qjp1
QklWkM2kJAgk2Mb/NHnEEQFtqnxj9A3H8yzj44th0drfMGU7xLkGj3wW1fT4FXMp
5qGEx5epB07Ag+K0OLk/D9GXkm6xnkFh6/LQOEZ1g0RVNW8n6ccJflh1ZT/aoMGR
vZRc3K1498PIYbyaxR/INoVdW8803ttNv469fOhjLQAwSzTPeXp7bc5Y6A6rXLvW
uTR8Tm3bcu87FYPrTMosQqN6kC4b86OHYrwCAmiqG1TyKIx4c0fBS7FasbdvbLqw
HIX2FcQGYm8VW9nYEkqrw0/j5XNQ1zC5Udy2OJOwTiio+v1+KisnR8Z254thzZ9b
spYyeaC/M1BF06QjEZb9tS3EDoA6nFGWMr6rHC5Y2zUcj/jQpfdbwOyatupmvP6m
iATmONfNRECXaOmZr+MN5s2sJFZ/Td9DIIaIo6VgSiuaOJWgrxDguQcwe+d9H+g8
0aLyvfzEuxZ2/hxdDRRo
=zczP
-----END PGP SIGNATURE-----

Re: Dumb MX Record Question

2009-12-02T08:36:52Z

Wow. Usually I just lurk on the list, but wow. So if I understand your priorities in order of most preferred to least:

#1. Beating yourself on the head with a hammer.
#2. Asking a question on the qmail list and lying about knowing an RFC.
#3. Looking up an RFC that you probably already know and reading a portion of it.

I mean, really. I know RFCs aren't exactly at the reading level of Harry Potter, but if you KNOW that the answer lies in an RFC, -AND- you know which RFC it is... I mean, that is just another special level of laziness to have all that information at your fingertips and yet you have to ask people to read it to you. And it's one thing to at least be polite about it, but to insult the people on the list while asking your question? That's enough to get me out of my lurking status.

As someone who hires and fires people and runs with the crowd that does the same, I can honestly say that you will not get far in this world with that type of attitude.

Now back to my lurking...

On 12/2/2009 10:51 AM, Datesfat Chicks wrote:

On Wed, Dec 2, 2009 at 10:50 AM, Datesfat Chicks <datesfat.chicks@...> wrote:

On Wed, Dec 2, 2009 at 10:22 AM, Shepherd Nhongo <shepherdzw@...> wrote:

On Wed, Dec 2, 2009 at 5:15 PM, Datesfat Chicks <datesfat.chicks@...> wrote:

If I set the MX record for a domain (mydomain.com), what do the RFCs say about how a delivery attempt will be made to whatever@...?

Specify the RFC's you are refering to ?

I'm assuming that since it is a subdomain (list.mydomain.com), it will use the MX record for the domain (mydomain.com)?

Sorry, dude, I'm a veteran of the qmail list. Whenever I'm feeling self-abusive and beating myself on the head with a hammer just isn't making the grade, I subscribe to the list again.

You aren't going to fool me!

This is the single most toxic list is the history of toxic lists.

You are setting up to beat on me. As soon as I identify the RFC's, you're going to respond with something like "You know where the information is located, why don't you read it?".

So, for the record, I have no idea which RFC's are involved. : )

I know all the tricks on this list. My KungFu is first rate.

The question still stands: If the MX for mydomain.com is set up, how will delivery to subdomain.mydomain.com be attempted?

Thanks.

Datesfat

RE: Dumb MX Record Question

2009-12-02T08:08:23Z

De : Datesfat Chicks [mailto:datesfat.chicks@...]
Envoyé : 2 décembre 2009 10:15
À : qmail@...
Objet : Dumb MX Record Question

> If I set the MX record for a domain (mydomain.com), what do the RFCs say
about how a delivery attempt will be made to whatever@...?

I believe RFC states that other SMTP servers will try to lookup MX record
for list.mydomain.com, if it fails it will lookup A record of
list.mydomain.com and connect to its port 25. If there is no A record I
think RFC says it will bounce, but I invite other people to correct me if
I'm wrong :)

You may find this information by reading carefully:
http://tools.ietf.org/html/rfc5321#section-5

> I'm assuming that since it is a subdomain (list.mydomain.com), it will use
the MX record for the domain (mydomain.com)?

I think not, you need to configure appropriate DNS records for this, and I
think you should do this.

> Thanks, Datesfat

Have a nice day

Maxime

Re: Dumb MX Record Question

2009-12-02T07:51:49Z

On Wed, Dec 2, 2009 at 10:50 AM, Datesfat Chicks <datesfat.chicks@...> wrote:

On Wed, Dec 2, 2009 at 10:22 AM, Shepherd Nhongo <shepherdzw@...> wrote:

On Wed, Dec 2, 2009 at 5:15 PM, Datesfat Chicks <datesfat.chicks@...> wrote:

If I set the MX record for a domain (mydomain.com), what do the RFCs say about how a delivery attempt will be made to whatever@...?

Specify the RFC's you are refering to ?

I'm assuming that since it is a subdomain (list.mydomain.com), it will use the MX record for the domain (mydomain.com)?

Sorry, dude, I'm a veteran of the qmail list. Whenever I'm feeling self-abusive and beating myself on the head with a hammer just isn't making the grade, I subscribe to the list again.

You aren't going to fool me!

This is the single most toxic list is the history of toxic lists.

You are setting up to beat on me. As soon as I identify the RFC's, you're going to respond with something like "You know where the information is located, why don't you read it?".

So, for the record, I have no idea which RFC's are involved. : )

I know all the tricks on this list. My KungFu is first rate.

The question still stands: If the MX for mydomain.com is set up, how will delivery to subdomain.mydomain.com be attempted?

Thanks.

Datesfat

Re: Dumb MX Record Question

2009-12-02T07:42:51Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wednesday, December 2 at 10:15 AM, quoth Datesfat Chicks:
>If I set the MX record for a domain (mydomain.com), what do the RFCs say
>about how a delivery attempt will be made to whatever@...?
>
>I'm assuming that since it is a subdomain (list.mydomain.com), it will use
>the MX record for the domain (mydomain.com)?

Nope, it will use the A record for list.mydomain.com.

Originally, the idea of SMTP was that messages to user@...
would be delivered to HOST.DOMAIN.COM. Later, it was decided that DNS
records could be used to redirect that mail (first with MD and MF
records, which were later replaced by MX records).

The defining paragraph, from RFC 5321 is section 5.1, page 69:

5.1 Locating the Target Host

Once an SMTP client lexically identifies a domain to which mail
will be delivered for processing (as described in Sections 2.3.5
and 3.6), a DNS lookup MUST be performed to resolve the domain
name (RFC 1035 [2]). The names are expected to be fully-qualified
domain names (FQDNs): mechanisms for inferring FQDNs from partial
names or local aliases are outside of this specification. Due to
a history of problems, SMTP servers used for initial submission of
messages SHOULD NOT make such inferences (Message Submission
Servers [18] have somewhat more flexibility) and intermediate
(relay) SMTP servers MUST NOT make them.

In other words:

1. SMTP senders must look for the MX record of the specific
recipient FQDN (i.e. the full host name).
2. If no MX record is present, look for an A record, and treat it
as an MX record.
3. If an MX record IS present, one CANNOT use the A record.

There is no "look up the parent domain".

Think about this also from the DNS perspective. Subdomains can be
delegated. If you delegate list.yourdomain.com to some other entity,
why would it be useful to allow you to define where their mail goes?
Or, put another way, if you fail to define an MX record for
yourdomain.com, should clients check to see if there's an MX record
for com? Of course not.

~Kyle
- --
Habits of thought persist through the centuries; and while a healthy
brain may reject the doctrine it no longer believes, it will continue
to feel the same sentiments formerly associated with that doctrine.
-- Charlotte Perkins Gilman
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJLFor7AAoJECuveozR/AWeTRQP/3jFhah7HVLGSD39Dp6fikRG
bb3/Sz+jMyMqqaZhMf0bJn6Izp13bU+EbsCluko5Tchoj+pyiIo3XUUMeh3xuIc0
p6XGjEFjMiJ01D0jBC/CIPkJc+P/9NdCj62LYRw+Fb2ak0d+DoWnNHCqkyjOskdS
PrEe3rvwck9UxCLrMXwwdD+OuHRYBljbzEfl4Cedv73R46HHKpM5Q10F6Oc1V4YE
VkGfxPEuv7uY5DkoTwN6mNmyqJM/2cGmuLDdvoIYRPPik4PZ5n+fEN9ay3vSgt6S
r9UotV8G+GFasrs8fcojjSnN6jUcPdp8zqophT8l+gbbwkmWh5c0yT9aiGt7uBRZ
xgcF3xArpRS37/469T41ue08VIe+JfA/9uHJm4yGuqdvG4POQoz4AN9+uE+Kzaju
RInm+9e4WRv7/mWk6CJZ99nepT9Ia4XQlsb2y8BYRcHD/4LgkVpsqaEm3bvNLAas
ApcZtuQyd2FZvKGutmvI7oCasVPOqykDZmnUvwupbWSE41CsNPYmdQlvglFc2m6H
3uQY44oEhiFi5vPL0u75PWlwBgiAIGY+vF0qg1ZNd0mIlXQF0J9z7669WNr84F5+
cYWhvNgrJkWuwPIHx9Y+5kHYeRzn/5rUcYuG858GfA1E0A4qb1du+mJmNcg5U5vp
WQRQ+Gviq7++6utREyPQ
=LSP5
-----END PGP SIGNATURE-----

Dumb MX Record Question

2009-12-02T07:15:24Z

If I set the MX record for a domain (mydomain.com), what do the RFCs say about how a delivery attempt will be made to whatever@...?

I'm assuming that since it is a subdomain (list.mydomain.com), it will use the MX record for the domain (mydomain.com)?

Thanks, Datesfat

Re: I cannot send mail from one of my internal hosts to another one

2009-11-30T07:55:45Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sunday, November 29 at 08:26 PM, quoth dihewo@...:
>> Well, what do your logs say?
>I just did a
> qmail-inject -fsender@... recipient@...
>recipient@... < /dev/shm/testmail.eml
>
> and the log is the following:

Okay... The problem you originally described was that messages to
hosts on your internal network would not be delivered if you had the
authentication information for your ISP in place, but that (obviously)
messages destined outside of your internal network that had to go
through your ISP could not be delivered if you didn't have that
information in place.

Which of those two situations was the case for this test? Which of
these recipients is destined for another host on your internal
network?

> Nov 29 20:07:51 fw qmail: 1259521671.062669 new msg 3288
>Nov 29 20:07:51 fw qmail: 1259521671.063845 info msg 3288: bytes 390 from
><sender@...> qp 13668 uid 0
>Nov 29 20:07:51 fw qmail: 1259521671.232167 starting delivery 150: msg 3288
>to local recipient@...
>Nov 29 20:07:51 fw qmail: 1259521671.233688 status: local 1/10 remote 0/2
>Nov 29 20:07:51 fw qmail: 1259521671.235445 starting delivery 151: msg 3288
>to remote recpient@...
>Nov 29 20:07:51 fw qmail: 1259521671.236594 status: local 1/10 remote 1/20
>Nov 29 20:07:51 fw qmail: 1259521671.776654 delivery 150: success:
>did_1+0+0/

This says that the message was successfully delivered *locally* (using
qmail-local, which is to say, not via the network) to
recipient@....

>Nov 29 20:07:51 fw qmail: 1259521671.781868 status: local 0/10 remote 1/20
>Nov 29 20:07:52 fw qmail: 1259521672.129374 delivery 151: success:
>www.xxx.yyy.zzz./Remote_host_said:_250_2.0.0_Ok:_queued_as_03EC348067/
>Nov 29 20:07:52 fw qmail: 1259521672.133025 status: local 0/10 remote 0/20
>Nov 29 20:07:52 fw qmail: 1259521672.134493 end msg 3288

And this says that the message was successfully delivered remotely to
what I assume is your ISP.

These logs show two successful deliveries, and therefore, no problem.
Did either of these messages not get to where it was supposed to go?
What problem occurred in this test?

>> My next guess would be that qmail is attempting to authenticate to the
>> internal hosts. Since those hosts do not understand the authentication
>> commands, perhaps those connections are being marked as errors. I
>> don't know which authentication patch you're using, but perhaps you
>> need to tell it to ignore authentication for your internal hosts.
>Shouldn't there be any error message, if that occurs.

Yes, there should be an error message of some kind if that occurs.

>> If that's true, then your logs should indicate that delivery (to
>> your
>> internal hosts) was attempted but failed.
>As you can see, there is no single error message currently.

If there's no error message, then as far as your server knows, the
deliveries occurred successfully.

Do the recipients receive these messages? Are the messages simply
disappearing? Do you get bounce messages? What are you seeing that
illustrates the problem?

~Kyle
- --
The greatest thing in family life is to take a hint when a hint is
intended---and not to take a hint when a hint isn't intended.
-- Robert Frost
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJLE+sAAAoJECuveozR/AWeofYQAK9RaUxlN0D/Dqqm3a03VbMj
0jIT0KHF7wPocmTCRGzZaH2CEJ4kw619fDA9BF7QWawY59ooSPQYi4YUfW7AAWTq
u7YC4Gyx8F7I1gIQvCfRMxcJaetuUijq74IMdWeCR8PKD37FiSK/mhGeFah/x01T
OMLueHHMkmuI4M6JbSl/VmhSicGmEzgLKCn5Vfz8AJhhs+A/2lv5NFk5gQeC6ZfN
aq+Cseh+D8Le0xrTw5cYfR2GK3SyNrrK4MTDplHn4uZeR5YYlYkvBbw1rS0m7TZC
+WTwb5QPdLckyRyljQQme7G0xM4YASHG/vhMdG2fyW4FG0xmGMZMf/Ty8Xil3hT0
WhPx8CtP+UI2AhoRo8de4xSaZs13SoB/fLWuNXrgxLPAMIwgfJ0LPgVwKsIesube
q/XeDXLB+LtOyUx0HPrMXJaJdoh/QOi0WT8+3Rd5s7pfPNBMfBFdBlfHOwQgoXiy
5x2CuccAc54cY1V+G2jTHhbHKEIKM5hoM59RcRVzwCrBvBma/g11NSceicSoXiWZ
tBDP5GDMXc9Oz6wZd8TNZEPCGGnLhisyemwxzPSG4DRQZEyCHaEbMb80H8xHDGha
K21OMR6S4M5BwcwcWkE3C4YPva5HeqYjiAEwqXDhjahLAq3YnlONxXTCVciLnOLp
kpF5Buxmt23f1pTYgawD
=EcK6
-----END PGP SIGNATURE-----

Re: qmail-smtpd => missing link => qmail-send

2009-11-30T07:43:42Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thursday, November 26 at 02:31 PM, quoth CoyoteTM-INC-Szeki:
> If you send a message to a qmail server, and you are successful, than
> you will se:
>
> ok_250_XXXXXXXXX_qp_12331 <= and this is the queue-pid number, what is
> comes up in the qmail-send logs.

Indeed.

> From this, It seems to me, that qmail-smtpd sees the queue PID,
> which can be the missing link.

Of course.

> Only what we have to do, to somehow log this into the qmail-smtpd
> log. (whitout mailforont, still don't like the idea)

Well, qmail-smtpd normally doesn't log *anything*, as you know (the
smtpd logs are just filled with tcpserver-generated entries). To get
it to log things, you have to edit the qmail-smtpd source. There are a
few qmail-smtpd logging patches out there, including my own (though
mine doesn't include the qp in the log entry at the moment). Find one
and apply it.

~Kyle
- --
Coffee is the common man's gold, and like gold, it brings to every
person the feeling of luxury and nobility.
-- Sheik Abd-al-Kadir
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJLE+gtAAoJECuveozR/AWeZL8P/0aUwbBPk1hgKlVC0v09dgTj
WBkd9d/caYHXqrwzrITeFrqV1Q1ws8JGP0AUNsb6JjbLY72xieQUHYdWyZoheEIA
UDJWeLDGIPf3AoxwkAIqKYyzwtMmcGTltuzytJJGIzSnOY1gjupwcTv3CZJTbwyn
qpJZo8oj+nnJrMx8Mavbwa53eWZUE0hZlfaWWiqS8sHXoYsmSGwXwUalFc+eqFgE
1TgNTVlIQrZtJttj12ImX/LJ9gmJ4oJg97rB1bgfIqu8ZE4yvQ0fr2aVfyZkKQ36
bJfAMv9/xbIM/6n9Nk6tZMzI0/gtW6ZriUng0zfcifsD0r7BP9eeVE0UUOv57A/Q
sxsiIefZ7sJX0N0GZhDW3mL4Kn/fGM/oKmpZ4zNQREgx0UbUvMkzWh8H/Xn3lTAG
crCV2T+DdS5ptRHoRBnc/vMkWtmnsMR/3fvV43uv/vj5NLY9VKXGGGFQMczUUqZ5
dmMQkJKOISlG6aicmtVwbvqaRnPmCcgqFHnSzXTrTyjfLICPckl6UeqRAWIe6Efr
pGX+0LBOY+5f17GUn0ZbQkrkCRIPR3BynPFrMllV0P9icgv/TJw0dIzWheqBbPor
9+VqmPre51v/IJxin2+nUQkByXzZ5vRLjFbThurbTGOvPiqV30xdqHBhd/s6APr3
cciQckxPtGuErbDQL+Bm
=OdZA
-----END PGP SIGNATURE-----

Re: Simple Message rewrite

2009-11-29T14:07:29Z

On Sunday, November 29 at 09:06 PM, quoth Steve Wilson:
> The reason for wanting to do this at MTA level is so I one central
> place for configuring it. I use 2 dual boot machines and a triple
> boot macbook, giving 7 different MUAs that would need setting up.

For what it's worth, it's relatively easy to synchronize mutt config
files using something like cvs.

But, you can alter stuff like that relatively easily using a wrapper
around qmail-remote. For example:

#!/bin/bash
host="$1"
sender="$2"
size="$3"
shift 3
recips=( "$@" )
for F in "${recips[@]}"; do
if [ -f /var/qmail/redirects/"$F" ] ; then
config=`cat /var/qmail/redirects/"$F"`
if [ "$sender" == `echo $config | cat -d: -f1` ] ; then
sender=`echo $config | cat -d: -f2`
break
fi
fi
done
exec /var/qmail/bin/qmail-remote.orig "$host" "$sender" "$size" "${recips[@]}"

Then, all you need to do is create the directory
/var/qmail/redirects/, put the addresses that need to trigger a
sender-redirect in there, and put the sender's address you want to
redirect and the new the sender to be inside that file, like so:

echo 'me@mydomain:me-qmail@mydomain' > \
/var/qmail/redirects/qmail@...

~Kyle
--
People who would give up their Freedom for security deserve neither.
-- Benjamin Franklin

Re: Simple Message rewrite

2009-11-29T13:06:47Z

Charles Cazabon wrote:

> Steve Wilson <qmail@...> wrote:
>> Is anyone aware of a filter I can use within qmail to rewrite the
>> sender, both in the message and the env.
> [...]
>> Short of writing my own to do things I'd like something I can check the
>> destination address, and if the sender address matches change it to the
>> list specific address, preferably with control file based config.
>
> You needn't necessarily do it at the MTA level. Many MUAs have the ability to
> set the sender address based on the recipient address. GUI MUAs frequently
> call it "profile selection" or something. mutt lets you do it very easily; I
> use mutt for this.
>
> Charles

The reason for wanting to do this at MTA level is so I one central place
for configuring it. I use 2 dual boot machines and a triple boot
macbook, giving 7 different MUAs that would need setting up.

Steve.

Re: I cannot send mail from one of my internal hosts to another one

2009-11-29T11:26:10Z

Hello Kyle,

-------- Original-Nachricht --------
Datum: Sun, 25 Oct 2009 01:40:34 -0500
Von: Kyle Wheeler <kyle-qmail@...>
An: dihewo@...
CC: qmail@...
Betreff: Re: [Click the star to watch this topic] I cannot send mail from one of my internal hosts to another one

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Saturday, October 24 at 07:02 PM, quoth dihewo@...:
> I have an entry for each host, that can receive mail, in this file.
> That is why I don't understand, what the problem can be.

Well, what do your logs say?

I just did a

qmail-inject -fsender@... recipient@... recipient@... < /dev/shm/testmail.eml

and the log is the following:

Nov 29 20:07:51 fw qmail: 1259521671.062669 new msg 3288
Nov 29 20:07:51 fw qmail: 1259521671.063845 info msg 3288: bytes 390 from <sender@...> qp 13668 uid 0
Nov 29 20:07:51 fw qmail: 1259521671.232167 starting delivery 150: msg 3288 to local recipient@...
Nov 29 20:07:51 fw qmail: 1259521671.233688 status: local 1/10 remote 0/2
Nov 29 20:07:51 fw qmail: 1259521671.235445 starting delivery 151: msg 3288 to remote recpient@...
Nov 29 20:07:51 fw qmail: 1259521671.236594 status: local 1/10 remote 1/20
Nov 29 20:07:51 fw qmail: 1259521671.776654 delivery 150: success: did_1+0+0/
Nov 29 20:07:51 fw qmail: 1259521671.781868 status: local 0/10 remote 1/20
Nov 29 20:07:52 fw qmail: 1259521672.129374 delivery 151: success: www.xxx.yyy.zzz./Remote_host_said:_250_2.0.0_Ok:_queued_as_03EC348067/
Nov 29 20:07:52 fw qmail: 1259521672.133025 status: local 0/10 remote 0/20
Nov 29 20:07:52 fw qmail: 1259521672.134493 end msg 3288

My next guess would be that qmail is attempting to authenticate to the
internal hosts. Since those hosts do not understand the authentication
commands, perhaps those connections are being marked as errors. I
don't know which authentication patch you're using, but perhaps you
need to tell it to ignore authentication for your internal hosts.

Shouldn't there be any error message, if that occurs.
I have no password specified for the internal hosts. Currently my smtproutes_users looks like this:

:host.my.domain
:smtp.relay.domain|user|password

If that's true, then your logs should indicate that delivery (to your
internal hosts) was attempted but failed.

As you can see, there is no single error message currently.

I am still stuck.

~Kyle

Dieter

Re: Simple Message rewrite

2009-11-28T19:16:01Z

Steve Wilson <qmail@...> wrote:
> Is anyone aware of a filter I can use within qmail to rewrite the
> sender, both in the message and the env.
[...]
> Short of writing my own to do things I'd like something I can check the
> destination address, and if the sender address matches change it to the
> list specific address, preferably with control file based config.

You needn't necessarily do it at the MTA level. Many MUAs have the ability to
set the sender address based on the recipient address. GUI MUAs frequently
call it "profile selection" or something. mutt lets you do it very easily; I
use mutt for this.

Charles
--
--------------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at: http://pyropus.ca/software/
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
--------------------------------------------------------------------------

Simple Message rewrite

2009-11-28T15:32:49Z

Is anyone aware of a filter I can use within qmail to rewrite the
sender, both in the message and the env.

I'm subscribed to several mailing lists similar to this one. Like
several people I know with their own domains I use addresses specific to
the mailing list, qmail@ for here. I'd rather not be setting up multiple
email accounts everywhere I check mail.

Short of writing my own to do things I'd like something I can check the
destination address, and if the sender address matches change it to the
list specific address, preferably with control file based config.

Regards

Steve.

Re: tcpserver, qmail-smtpd, qmail-queue and filter Qs

2009-11-26T19:46:59Z

Jost,

On 2009-11-27 08:01, Jost Krieger wrote:

> On Thu, Nov 19, 2009 at 10:16:37AM -0600, Kyle Wheeler wrote:
>
> Sorry to comeso late, but this all is a misunderstanding.
>
>> On Thursday, November 19 at 11:48 AM, quoth Philip Rhoades:
>>> In my setup tcpserver execs greylite which eventually execs
>>> qmail-smtpd. Greylite uses the to and from IP addresses of the tcp
>>> communication - is any of the message itself (header lines?, body?)
>>> available at this point or only after qmail-smtpd runs?
>>
>> As other folks have pointed out, the short answer is "no".
>> ...
>> Before qmail-smtpd runs, you know only the information about the
>> connection itself: the IP address (and hostname) of the connecting
>> client, the port numbers that are being used.
>
> That's not true (in the case of greylite).
>
> I used greylite for a while (and gave up for reasons of database
> contention). Now I use a variant of greydaemon (thanks to John Levine),
> but that needs patching qmail-smtpd (which we have been doing for ten
> years anyway ...).
>
> Greylite is using "command line chainig", but not simple "exec
> chaining". It does indeed set up a pair of pipes, then forks and execs.
> After that, it listens into the SMTP stream. It will intercept the SMTP
> dialogue for greylisting, and turn into a passthrough if everything is
> fine. It never cares for anything after DATA, but it sees the MAIL FROM
> and RCPT TO.

Right - which would allow me to do some more filtering except that as
someone else pointed out - MAIL FROM and RCPT TO don't necessarily
correspond to From: and To: - I have checked most of my problem mails
and they would not be stopped by such filtering unfortunately . .

> Qmail-smtpd doen't notice, because it sees the complete SMTP dialogue,
> normally.
>
> So greylite is like recordio in interface and function.

Thanks for the extra info! - it is appreciated.

Regards,

Phil.
--
Philip Rhoades

GPO Box 3411
Sydney NSW 2001
Australia
E-mail: phil@...

Re: tcpserver, qmail-smtpd, qmail-queue and filter Qs

2009-11-26T13:01:10Z

On Thu, Nov 19, 2009 at 10:16:37AM -0600, Kyle Wheeler wrote:

Sorry to comeso late, but this all is a misunderstanding.

> On Thursday, November 19 at 11:48 AM, quoth Philip Rhoades:
> > In my setup tcpserver execs greylite which eventually execs
> > qmail-smtpd. Greylite uses the to and from IP addresses of the tcp
> > communication - is any of the message itself (header lines?, body?)
> > available at this point or only after qmail-smtpd runs?
>
> As other folks have pointed out, the short answer is "no".
> ...
> Before qmail-smtpd runs, you know only the information about the
> connection itself: the IP address (and hostname) of the connecting
> client, the port numbers that are being used.

That's not true (in the case of greylite).

I used greylite for a while (and gave up for reasons of database
contention). Now I use a variant of greydaemon (thanks to John Levine),
but that needs patching qmail-smtpd (which we have been doing for ten
years anyway ...).

Greylite is using "command line chainig", but not simple "exec
chaining". It does indeed set up a pair of pipes, then forks and execs.
After that, it listens into the SMTP stream. It will intercept the SMTP
dialogue for greylisting, and turn into a passthrough if everything is
fine. It never cares for anything after DATA, but it sees the MAIL FROM
and RCPT TO.

Qmail-smtpd doen't notice, because it sees the complete SMTP dialogue,
normally.

So greylite is like recordio in interface and function.

Jost
--
| Helft Spam ausrotten! HTML in Mail ist unhöflich. |
| Postmaster, JAPH, manchmal Wahrsager am RZ der RUB |
| Bitte immer an Funktionsadressen schreiben: Postmaster@... |

Re: limit outgoing email size but not incoming

2009-11-26T07:39:22Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thursday, November 26 at 09:37 AM, quoth Markus Stumpf:
> Next you have to define what you mean by incoming and outgoing.

This is key (especially since, without something like SMTP-AUTH, it
could be pretty easy for a spammer to work around).

Another way to do it is to place the restriction in a wrapper around
qmail-remote, forcing a failure to deliver if the remote message is
too big. This clearly delineates between "incoming" and "outgoing"
(because incoming messages never go through qmail-remote), but means
that the too-large messages get into the queue even though they'll
never be delivered.

~Kyle
- --
Nothing gives one person so great advantage over another as to remain
always cool and unruffled under all circumstances.
-- Thomas Jefferson to Francis Eppes, 1816
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJLDqEpAAoJECuveozR/AWetY8QAJvOeMqJRp+Azfn58O9e5nEd
ChpD7fR+ZQlHg/Ox+iRjZH2n5Hrb8ZSXY60AivD88TN6JukPVQHTmQjw3Oh3ydzV
BqDciQBt3vCvVLpTOfUT23biwdh2/jNgENK/xjG1VIDofjJHOXXQ19XcOt2u5ReS
Khb9slaIbo2MS0e69FUJxeuI+GpRNd4t0xfWpQ9LdsLno396Yer9MwqREvyZkqmD
BOTElj1+LuWMtO1gD4nqQ/ysOf/NFnapC3NAEvGDKWc5tbvbWVoLE3tAPWnKD9zK
xSlJL1rK9TNBvscwTAUG0+4opHa2dx4Ne0gFI9SFttBZRr9s+leqb21ukE6EFkEm
YY1CVNAurEFq3Gtmf0RtK/sGcTIccR1El1z32v9cFTDWnfjHCyvg4YPOQwIUAzFL
Xc2hoBu18h7QkrG8N0vnF5LwaUtaiyDGc0T2EZ/MCmKobIlXVfzDBSQukc4Oq50B
M+Z2VVsIoGizCqQ43zAUYRdaFLWaS49gepr42MP+Ua+b4Jl2drKIIBR7XLRy4s0u
UTVspP3+Abo06zLmaWstQKqpxr1Pyl7DwSbRFYNzSovbPThIUSRioSWK4165me86
jIA4u2EFk78l2avgiErSVwniUyygt46pW0jV8WNThGynJAFMA+Veym/4h0Y6dSSB
723MCyQJX2AgkZtdEMts
=6kre
-----END PGP SIGNATURE-----

Re: limit outgoing email size but not incoming

2009-11-26T07:36:05Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thursday, November 26 at 08:35 AM, quoth Philipp Kolloczek:
> Well, you can do like Hugo Monteiro suggested. Without patching
> qmail sources there will be no other way.

Well, now, that's just an open challenge.

You can also do it with a qmail-queue wrapper (a convenient one is
qmail-qfilter). If you rename qmail-queue and qmail-qfilter
appropriately, you can make it apply to locally (e.g.
/usr/sbin/sendmail) produced email as well.

~Kyle
- --
It only takes 20 years for a liberal to become a conservative without
changing a single idea.
-- Robert Anton Wilson
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iQIbBAEBCAAGBQJLDqBPAAoJECuveozR/AWeD94P9ic2QkO3/wmWI6lGIifEOyl7
OkqDBLj8SXA3qm5KbNCG0lDaw8b5H/xDSjbz3CSh5xyzfh1lGStFRDrfTj5p2xmS
MEXJWEH6HH0wIzjCuev6Zxm8kMOSaCQcxHHN7xTUHQzoay+VZ48E35Z0bB/sXbCe
JNYg8UG9hMvUtk9DqmhDWFFKh0liO/elOHXnnGpFW6eAC8TpuIVRY8uDEym4yLQi
+IP9de9yOshotvolA3aGphrR/KNk1+w3YMDz/uMXql29gve1OdummUf7heYeTiAJ
xi9Ja//9AtYZkCtcMJprGBgPhXsW7AfaCrzm5PQyhQ0PER/ysD6tOGDM4sZEVouT
i6CrNI5Xc6rw78rH4sbcdOzIrLV3f9tWVhTz9HkRCMSGsZYUfIAFRJPG5YS34BbL
uYihGv18A5ez0SnwEcsfRx3AADgsUGODd/JZiRG94w1CJtr5NDJhpL/13Oa3Cmpz
iU/ZzIZmzQjS4USKleACpS0XUl7Z+6/7bGLmIV26W/CByeIENq2ByNFLZWcniLO+
9aXvVC7B4Mm16+YjjdffY/DHPEB8E+UUbFiXvN+l9IXlmlSh3R9pKiIxNsRjVzzz
RYz/AZLMOL7cxNENIG0nhoLn23RyQ3D+oxOyOvly29NZX91wMqcXKxK1PelkWpQW
HdEsxwGFLMterv3RORk=
=f5lG
-----END PGP SIGNATURE-----

Re: qmail-smtpd => missing link => qmail-send

2009-11-26T05:31:43Z

If you send a message to a qmail server, and you are successful, than
you will se:

ok_250_XXXXXXXXX_qp_12331 <= and this is the queue-pid number, what is
comes up in the qmail-send logs.

If I make a connection to an qmail smtpd szerver, than I communicate
with the qmail-smtpd program, and this program sends back to me the answers.

From this, It seems to me, that qmail-smtpd sees the queue PID, which
can be the missing link. Only what we have to do, to somehow log this
into the qmail-smtpd log. (whitout mailforont, still don't like the idea)

This is right or not?

Peter, Szekeres

Bruce Guenter írta:

> On Wed, Nov 11, 2009 at 06:43:45PM +0100, CoyoteTM-INC-Szeki wrote:
>>> Easily, and not very weird. I do it in mailfront. Add code to dump the
>>> accept_buf to stderr in acceptmessage() in qmail-smtpd.c
>> So it is possible to get the qmail-queue pid info at the stage, when
>> qmail-smtpd fires it up.
>
> Certainly. It's the "qp" variable in smtp_data.
>
>> As I have read and understand so far, mailfront replaces qmail-smtpd,
>> which idea I fear of. (or makes a new frontend for qmail-smtpd?)
>
> mailfront replaces qmail-smtpd, yes, as well as qmail-qmqpd and
> qmail-qmtpd, and qmail-popup and qmail-pop3d.
>
>> Is it a hard work to modify qmail-smtpd.c to log that info? (without
>> mailfront)
>
> Yes. In acceptmessage, after each "out" call, add something like:
>
> write(2,X,str_len(X));
>
> where "X" is the parameter to out. Alternately, you could modify the
> out function to write to stderr as well, possibly with another substdio
> buffer. This will let you see all SMTP responses, for good and bad (can
> result in log spam).
>
> PS. this should go back to the qmail mailing list.
>

Re: limit outgoing email size but not incoming

2009-11-26T00:37:40Z

On Thu, Nov 26, 2009 at 10:29:17AM +0800, packets wrote:
> As I know, both incoming and outgoing will reject emails more than
> 3mb and I don't want to do that.

This is not correct.
DATABYTES only affects incoming messages per qmail-smtpd.
Messages created locally or uploaded and sent eg. via a webmail system
are *NOT* affected.

Next you have to define what you mean by incoming and outgoing.
Do you mean by "incoming" *every* message from *every* user that
would be delivered to a local address/mailbox?
And outgoing would be every message for a non-local user/mailbox?
How about messages coming in for a local user that has a forward to an
external address?
Next is error handling.
At what point do you want to reject the message? Somehow the message has
to be uploaded to your server. Do you want to reject it at that point?
If not, how will you handle the already injected message? Bounce it back
to the sender?

I guess to accomplish what you want I'd modify qmail-smtpd.c in
smtp_rcpt().

Change
------------------------------------------------------------------------
if (!stralloc_0(&rcptto)) die_nomem();
out("250 ok\r\n");
}
------------------------------------------------------------------------
to
------------------------------------------------------------------------
if (!stralloc_0(&rcptto)) die_nomem();
if (addrallowed()) databytes = 0;
out("250 ok\r\n");
}
------------------------------------------------------------------------

What does it do?
For every connection that delivers a message to a local recipient
(addrallowed() results in true) databytes is set to unlimited (aka
turned off).
If you now set DATABYTES to 3MB then every connection that requires a relay
operation will be restricted to 3 MB, every connection with a local
delivery will not.

CAVEAT!!! SMTP allows more than one recipient with one message.
the modification turns off DATABYTES if *ANY ONE* of multiple
recipients of the message is local. So if there is a message
of size 5 MB with 1 local and 1 remote recipient it will be accepted and
delivered remote, even with the 5 MB size.

Hope that helps,

\Maex

RE: limit outgoing email size but not incoming

2009-11-25T23:35:21Z

Hello.

> 3mb. As I know, both incoming and outgoing will reject emails more
> than 3mb and I don't want to do that. I want to
> accept incoming emails regardless of any size but I want to limit my
> outgoing smtp to 3mb.

Well, you can do like Hugo Monteiro suggested.
Without patching qmail sources there will be no other way.

If your sender do smtp-auth, it may be a way to alter qmails code
to redefine databytes with a given value if the auth request was
successful. Depending of your qmail you have to change more than
one function in different modules.

Greets
Phil.

Re: limit outgoing email size but not incoming

2009-11-25T19:10:36Z

packets wrote:

> Is it possible that I impose restriction on senders not to send emails
> more than 5mb email? I have read databytes and I
> imposed it to one of my server with 15mb. However, I want to implement
> it to another server but this time it must be
> 3mb. As I know, both incoming and outgoing will reject emails more
> than 3mb and I don't want to do that. I want to
> accept incoming emails regardless of any size but I want to limit my
> outgoing smtp to 3mb.
>
>

You can specify a different DATABYTES env var for each tcpserver rule
that you have. The existence of that env variable will overwrite the
default value set in the databytes file, if any.

Regards,

Hugo Monteiro.

--
ci.fct.unl.pt:~# cat .signature

Hugo Monteiro
Email : hugo.monteiro@...
Telefone : +351 212948300 Ext.15307
Web : http://hmonteiro.net

Centro de Informática
Faculdade de Ciências e Tecnologia da
Universidade Nova de Lisboa
Quinta da Torre 2829-516 Caparica Portugal
Telefone: +351 212948596 Fax: +351 212948548
www.ci.fct.unl.pt apoio@...

ci.fct.unl.pt:~# _

limit outgoing email size but not incoming

2009-11-25T18:29:17Z

Is it possible that I impose restriction on senders not to send emails more than 5mb email? I have read databytes and I
imposed it to one of my server with 15mb. However, I want to implement it to another server but this time it must be
3mb. As I know, both incoming and outgoing will reject emails more than 3mb and I don't want to do that. I want to
accept incoming emails regardless of any size but I want to limit my outgoing smtp to 3mb.

Re: change filename

2009-11-24T00:24:31Z

On Tue, Nov 24, 2009 at 03:50:59PM +0800, packets wrote:
> I implement safecat so that I can create another copy of emails outside
> Maildir directory. I want to create a script wherein it will tar all files
> if the file was receive lets say November. All emails received last October
> will not be included on tar.

You may want to look at the GNU tar -N/--newer/--after-date options.
They allow to specify "DATE" as (from "info tar"):
* Calendar date items:: 19 Dec 1994.
* Time of day items:: 9:20pm.
* Time zone items:: EST, PDT, GMT.
* Day of week items:: Monday and others.
* Relative items in date strings:: next tuesday, 2 years ago.
* Pure numbers in date strings:: 19931219, 1440.
* Seconds since the Epoch:: @1078100502.

\Maex

Re: change filename

2009-11-23T23:50:59Z

I implement safecat so that I can create another copy of emails outside Maildir directory. I want to create a script
wherein it will tar all files if the file was receive lets say November. All emails received last October will not be
included on tar. Since this is an old server and there are files wayback last year, its hard to use mtime options of
find command though still possible by calculating days. If I can append month and date on the filename, it could make my
life easier.

>
> But the main question to me is:
> What problem are you trying to solve?
>

Re: change filename

2009-11-23T23:01:32Z

Hi,

the original spec is here:
http://cr.yp.to/proto/maildir.html
Maildir++ spec is here:
http://www.inter7.com/courierimap/README.maildirquota.html

Those define naming rules, which programs should adopt, to guarantee some
interoperability.

On Tue, Nov 24, 2009 at 11:18:26AM +0800, packets wrote:
> Is it possible to change filename of all incoming emails before it will be
> deliver to Maildir?

Is the question:
- is it possible like in "how can I do it"?
Then you might want to take a look at
http://www.jeenyus.net/linux/software/safecat.html
and modify the source code to produce the new names
Or modify qmail-local.c around line 700 in procedure maildir_child().
or is the question
- is it possible like in "will I break things"?
The you must check with your software accessing the maildirs.

But the main question to me is:
What problem are you trying to solve?

The information you try to add to the name is already stored in the
inode. You can access it with eg. "/bin/ls -l"
If you want a more easy to process list use (GNU) find like:
find /path -type f -printf "%CY%Cm %p\n"

\Maex

change filename

2009-11-23T19:18:26Z

Is it possible to change filename of all incoming emails before it will be deliver to Maildir? Let's say I have a
filename 1258692713.M653901P24650.localhost. Can I change it to 1258692713.M653901P24650-200911.localhost. Can I apply
the output of the command "date +%F" in each incoming emails to append on the filename before it reach Maildir?

Re: Checking sender ID

2009-11-21T08:57:00Z

Hi Wong

--On Samstag, November 21, 2009 14:26:42 +0800 Wong <wongbali@...>
wrote:

> Dear All,
>
> So far, our qmail allow all user sent messages as long as they are in our
> LAN subnet.
>
> I need advise how to limit qmail to allow users sending out messages
> (only) if they use company domain. By that policy, user only able to send
> out messages with 2 conditions:
>
> 1. In LAN subnet
> 2. Use specific (company) domain
>
> All incoming messages should not effected by this setting. Is it possible?

Plain (= vanilla) qmail does not support this restriction.

However, you can use my 'Mail From: Address Verification' (MAV) patch for
qmail which allows you to setup those filter mechanisms.
MAV is also part of my SPAMCONTROL.

http://www.fehcom.de/qmail.html

regards.
--eh.

Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/

Checking sender ID

2009-11-20T22:26:42Z

Dear All,

So far, our qmail allow all user sent messages as long as they are in our
LAN subnet.

I need advise how to limit qmail to allow users sending out messages (only)
if they use company domain. By that policy, user only able to send out
messages with 2 conditions:

1. In LAN subnet
2. Use specific (company) domain

All incoming messages should not effected by this setting. Is it possible?

Thank you so much for your help.

Best Rgds,

Wong